[PATCH] D22377: [SCEV] trip count calculation for loops with unknown stride

[Sanjoy Das via llvm-commits]

sanjoy requested changes to this revision.
sanjoy added a comment.
This revision now requires changes to proceed.

Hi Pankaj,

There are three issues with the current patch:

- Even after proving a non-negative stride, you cannot generally assume a non-zero stride.  A zero stride is possible if the loop has a side effect in it (i.e. a volatile read or write, or some IO). If the loop does not have a side effect then running forever is undefined behavior, so proving the loop does not have side effects + `ControlsExit` should be enough to prove that stride is non-zero.  A good place to compute it is in a common function that also computes `loopHasNoAbnormalExits` at the same time (to avoid traversing the loop body twice).
- It looks like you're saying if `Start` - `Stride` < `RHS` then the loop cannot be a single iteration loop.  I think that is incorrect, what if we have:
  - `Start` = `-1`, `Stride` = `-2`, `RHS` = `5` for an unsigned compare? `Start` - `Stride` = `1` which is u< `RHS`, but if the backedge is controlled by `{-1,+,-2}` u< `5` then it won't be taken even once.
  - `Start` = `INT_MAX`, `Stride` = `-1`, `RHS` = `5` for a signed compare? `Start` - `Stride` = `INT_MIN` which is s< `RHS`, but if the backedge is controlled by `{INT_MAX,+,-1}` s< `5` then it won't be taken even once.

    I think the right precondition is `Start` < `RHS` -- if that precondition is true then we know that `{Start,+,Stride}` is true on the first iteration, and if `Stride` is negative then we'll keep executing the loop till `{Start,+,Stride}` wraps.
- I don't think the logic as written is correct for unsigned compares.  I can legitimately have `{0,+,-1}<nuw>` u< `-1` execute one backedge (i.e. with a "negative" step).

Finally, we should also do this in `howManyGreaterThans` for symmetry,
but that's a separate change and does not need to be addressed in this
revision.


https://reviews.llvm.org/D22377