[PATCH] D91957: [Analysis] Migrate more high level cost functions to using InstructionCost

Paul Walker via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 30 05:15:50 PST 2020


paulwalker-arm added inline comments.


================
Comment at: llvm/lib/Transforms/Scalar/LoopUnswitch.cpp:306
 
-    Props.SizeEstimation = Metrics.NumInsts;
+    if (auto NumInsts = Metrics.NumInsts.getValue())
+      Props.SizeEstimation = *NumInsts;
----------------
david-arm wrote:
> CarolineConcatto wrote:
> > This assumes that  Metrics.NumInsts.getValue(), should we check  if Metrics.NumInsts.isValid()?
> > 
> Yeah I could have used isValid() here too, but getValue() returns an Optional<int>, which cannot be used directly anyway. I thought it was cleaner to write it this way and only reference Metric.NumInsts once. The alternative would be to write:
> 
> if (Metrics.NumInsts.isValid())
>   Props.SizeEstimation = *(Metrics.NumInsts.getValue());
> else
>   Props.SizeEstimation = std::numeric_limits<unsigned>::max();
> 
> Both ways of writing are functionally correct though! I've tended to use isValid() in places where we don't need to extract the value, i.e. for asserts, before doing comparisons or to bail out early from an optimisation.
> 
For the case where the number of instructions is unknown why not treat this as a reason not to unswitch the loop rather than than trying to second guess how `Props.SizeEstimation` will be used when determining a sensible value to set it to?  You could even add an LLVM_DEBUG to report when this happens.

I think this will be a general comment of my for any such code where we want to support not knowing the cost of something or more specifically when the cost is invalid and thus unusable.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91957/new/

https://reviews.llvm.org/D91957



More information about the llvm-commits mailing list