[PATCH] D89381: [SCEV] Use nw flag and symbolic iteration count to sharpen ranges of AddRecs

Max Kazantsev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 14 22:18:19 PDT 2020


mkazantsev added inline comments.


================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:5705
+  const SCEV *Start = AddRec->getStart();
+  const SCEV *End = AddRec->evaluateAtIteration(MaxBECount, *this);
+
----------------
fhahn wrote:
> efriedma wrote:
> > I'm concerned that evaluating at iteration MaxBECount won't do what you want.  In particular, if MaxBECount is larger than the number of steps required to violate nw, then the way you're comparing Start and End doesn't work.
> > 
> > The actual backedge-taken count at runtime can't be that large, of course, but MaxBECount is an approximation in general; I don't think we make any relevant guarantees.  In particular, if the step isn't constant, we can't get this right.
> > 
> > I think you could explicitly compute the largest number of non-wrapping iterations, and then take the minimum of that and MaxBECount to compute the "real" maximum count.
> > I think you could explicitly compute the largest number of non-wrapping iterations, and then take the minimum of that and MaxBECount to compute the "real" maximum count.
> 
> Unrelated to the patch directly, but I suppose we could also use this to clamp down the computed MaxBECount directly, if we do not already do so? But we still won't have a reliable way to indicate that the computed count can be used directly I think.
I don't think this situation is possible, but I don't have strong enough arguments to prove that. We can add an extra check that step * max num iterations must be known less than UINT_MAX for this type.


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

https://reviews.llvm.org/D89381



More information about the llvm-commits mailing list