[all-commits] [llvm/llvm-project] 6ab686: [LSR] Allow already invariant operand for ICmpZero...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6ab686eb86fb60ab63750dddd575ac92d8a1f9f9
      https://github.com/llvm/llvm-project/commit/6ab686eb86fb60ab63750dddd575ac92d8a1f9f9
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-07-15 (Fri, 15 Jul 2022)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
    M llvm/test/CodeGen/RISCV/rvv/sink-splat-operands.ll
    M llvm/test/Transforms/LoopStrengthReduce/RISCV/icmp-zero.ll

  Log Message:
  -----------
  [LSR] Allow already invariant operand for ICmpZero matching [try 2]

Changes since initial commit:

* Wrapping a pointer in an SCEV unknown hides the base, and SCEV is only able to compute a subtraction when the bases are known to be equal. This results in a SCEVCouldNotCompute flowing forward and triggering asserts. Test case added in d767b392.
* isLoopInvariant returns true for instructions outside the loop, but not necessarily *above* the loop. Since this code is allowed to visit uses of an IV outside of a loop, we have to make sure the operands of the compare are both invariant and dominating the header. Test case added in 2aed3cdb.

Original commit message follows...

The ICmpZero matching is checking to see if the expression is loop invariant per SCEV and expandable. This allows expressions inside the loop which can be made loop invariant to be seamlessly expanded, but is overly conservative for expressions which already *are* loop invariant.

As a simple justification for why this is correct, consider a loop invariant urem as RHS vs an alternate function with that same urem wrapped inside a helper call. Why would it be legal to match the later, but not the former?

Differential Revision: https://reviews.llvm.org/D129793