This is an archive of the discontinued LLVM Phabricator instance.

[NFC][llvm-exegesis] Refactor Analysis::SchedClassCluster::measurementsMatch()
ClosedPublic

Authored by lebedev.ri on Mar 28 2019, 11:20 AM.

Details

Summary

The diff looks scary but it really isn't:

  1. I moved the check for the number of measurements into SchedClassClusterCentroid::validate()
  2. While there, added a check that we can only have a single inverse throughput measurement. I missed that when adding it initially.
  3. In Analysis::SchedClassCluster::measurementsMatch() is called with the current LLVM values from schedule class and the values from Centroid.

3.1. The values from centroid we can already get from SchedClassClusterCentroid::getAsPoint().

This isn't 100% a NFC, because previously for inverse throughput we used `min()`. I have asked whether i have done that correctly in
https://reviews.llvm.org/D57647?id=184939#inline-510384 but did not hear back. I think `avg()` should be used too, thus it is a fix.

3.2. Finally, refactor the computation of the LLVM-specified values into Analysis::SchedClassCluster::getSchedClassPoint()

I will need that function for [[ https://bugs.llvm.org/show_bug.cgi?id=41275 | PR41275 ]]

Diff Detail

Repository
rL LLVM

Event Timeline

lebedev.ri created this revision.Mar 28 2019, 11:20 AM

Fixup last one error check, switch one more loop to llvm::zip().

courbet accepted this revision.Mar 29 2019, 3:52 AM

Thanks Roman.

This isn't 100% a NFC, because previously for inverse throughput we used min(). I have asked whether i have done that correctly in

https://reviews.llvm.org/D57647?id=184939#inline-510384 but did not hear back. I think avg() should be used too, thus it is a fix.

It should not matter if we assume that the output from the NumIterations measurements is accurate enough, so that's fine.

This revision is now accepted and ready to land.Mar 29 2019, 3:52 AM

Thanks Roman.

Thank you for the speedy review.

This isn't 100% a NFC, because previously for inverse throughput we used min(). I have asked whether i have done that correctly in

https://reviews.llvm.org/D57647?id=184939#inline-510384 but did not hear back. I think avg() should be used too, thus it is a fix.

It should not matter if we assume that the output from the NumIterations measurements is accurate enough, so that's fine.

Yes, that is what i thought, too. (median would be better, but avg is pretty good too.)

This revision was automatically updated to reflect the committed changes.