[PATCH] D35227: [LV] Don't allow outside uses of IVs if the SCEV is predicated on loop conditions

[Sanjoy Das via Phabricator via llvm-commits]

sanjoy added a comment.

In https://reviews.llvm.org/D35227#805493, @mkuper wrote:

> In https://reviews.llvm.org/D35227#805164, @mssimpso wrote:
>
> > I'm probably missing something obvious here. For external IV uses, we compute the end IV value assuming we're coming from the vector loop. But if we executed the vector loop, shouldn't the SCEV predicate have been true, which would mean that the PSEV was a safe assumption?
>
>
> You're not necessarily missing something obvious, I may be misunderstanding what PSCEV does here. If I understand correctly, PSCEV adds the assumption the IV doesn't overflow inside the loop. In this case, what I see is that it overflows on loop exit. So, either:
>  a) I misunderstand what PSCEV is doing here. :-)
>  b) PSCEV is wrong inside the loop.
>  c) The assumption PSCEV makes is correct, except on exit. If this is the case, then we can't use the SCEV we get to compute the value after the last iteration.


I can't be sure without understanding what exactly LV is trying to do here, but I suspect it is (c).  This is true not only of PSCEV but also of SCEV -- "{A,+,B} is nsw" means "the increment *operation* will not overflow if the backedge is taken" or "the increment *operation* may overflow on the last iteration".

Concretely, this is the predicate PSCEV uses to make {A,+,B} nsw:

  //   Step < 0, Start - |Step| * Backedge <= Start
  //   Step >= 0, Start + |Step| * Backedge > Start

So, e.g. if `Backedge` is 1, `Start` is INT_SMAX - 1 and `Step` is also 1, then the predicate will be true but on the last iteration the IV will be INT_SMAX and the increment *operation* will overflow (even though the overflowed value will not flow back into the IV's PHI node).

I have some more detail here: https://www.playingwithpointers.com/scev-integer-overflow.html


https://reviews.llvm.org/D35227