[PATCH] D104140: [SCEV] Allow negative steps for LT exit count computation

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 26 16:31:49 PDT 2021


reames added inline comments.


================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:11630
     // Precondition a) implies that if the stride is negative, this is a single
     // trip loop. The backedge taken count formula reduces to zero in this case.
     //
----------------
efriedma wrote:
> I think this needs to be "if the stride is negative and rhs is invariant".
I've given this a lot of thought and I don't believe this is true.  Let me explain why I think the code is correct, and you can poke holes in my reasoning.  :)

A negative stride must be greater than half of the addressable space.  Thus, we can only add a negative stride once without producing poison.

We check that if IV becomes poison that the loop must execute UB.  (This is the purpose of the ControlsExit check combined with the flag check.)  Thus, we don't have to worry about IV being poison, but another exit being taken before the one we're analyzing.  (This is important as it cuts off a *lot* of subtle edge case reasoning.)

As a result, we can infer that IV must add the step at most once.  Given we must increment IV on each iteration, this implies the backedge is not taken.

Note that the value of RHS did not appear in any of that logic.   

Chasing through the code for computeMaxBECountForLT, we appear to produce a correct/conservative result for a negative stride.  

Do you have a particular counter example in mind?

p.s. The means by which we prove poison triggers immediate UB could be generalized easily here.  Maybe something to explore in the future if we want to expand support for multiple exit loops.  


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

https://reviews.llvm.org/D104140



More information about the llvm-commits mailing list