[all-commits] [llvm/llvm-project] f5dd70: [LSR] Require non-zero step when considering wrap ...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f5dd70c58277d925710e5a7c25c86d7565cc3c6c
      https://github.com/llvm/llvm-project/commit/f5dd70c58277d925710e5a7c25c86d7565cc3c6c
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2024-01-11 (Thu, 11 Jan 2024)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
    M llvm/test/Transforms/LoopStrengthReduce/lsr-term-fold.ll

  Log Message:
  -----------
  [LSR] Require non-zero step when considering wrap around for term folding (#77809)

The term folding logic needs to prove that the induction variable does
not cycle through the same set of values so that testing for the value
of the IV on the exiting iteration is guaranteed to trigger only on that
iteration. The prior code checked the no-self-wrap property on the IV,
but this is insufficient as a zero step is trivially no-self-wrap per
SCEV's definition but does repeat the same series of values.

In the current form, this has the effect of basically disabling lsr's
term-folding for all non-constant strides. This is still a net
improvement as we've disabled term-folding entirely, so being able to
enable it for constant strides is still a net improvement.

As future work, there's two SCEV weakness worth investigating.

First sext (or i32 %a, 1) to i64 does not return true for
isKnownNonZero. This is because we check only the unsigned range in that
query. We could either do query pushdown, or check the signed range as
well. I tried the second locally and it has very broad impact - i.e. we
have a bunch of missing optimizations here.

Second, zext (or i32 %a, 1) to i64 as the increment to the IV in
expensive_expand_short_tc causes the addrec to no longer be provably
no-self-wrap. I didn't investigate this so it might be necessary, but
the loop structure is such that I find this result surprising.