[all-commits] [llvm/llvm-project] 3bc09c: [SCEVExpander] Allow udiv with isKnownNonZero(RHS)...

Philip Reames via All-commits all-commits at lists.llvm.org
Thu Jul 14 08:57:26 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3bc09c7da50a7bb2df51b1829f837f017da5ee34
      https://github.com/llvm/llvm-project/commit/3bc09c7da50a7bb2df51b1829f837f017da5ee34
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-07-14 (Thu, 14 Jul 2022)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
    M llvm/test/Transforms/LoopStrengthReduce/RISCV/icmp-zero.ll

  Log Message:
  -----------
  [SCEVExpander] Allow udiv with isKnownNonZero(RHS) + add vscale case

Motivation here is to unblock LSRs ability to use ICmpZero uses - the major effect of which is to enable count down IVs. The test changes reflect this goal, but the potential impact is much broader since this isn't a change in LSR at all.

SCEVExpander needs(*) to prove that expanding the expression is safe anywhere the SCEV expression is valid. In general, we can't expand any node which might fault (or exhibit UB) unless we can either a) prove it won't fault, or b) guard the faulting case. We'd been allowing non-zero constants here; this change extends it to non-zero values.

vscale is never zero. This is already implemented in ValueTracking, and this change just adds the same logic in SCEV's range computation (which in turn drives isKnownNonZero). We should common up some logic here, but let's do that in separate changes.

(*) As an aside, "needs" is such an interesting word here. First, we don't actually need to guard this at all; we could choose to emit a select for the RHS of ever udiv and remove this code entirely. Secondly, the property being checked here is way too strong. What the client actually needs is to expand the SCEV at some particular point in some particular loop. In the examples, the original urem dominates that loop and yet we completely ignore that information when analyzing legality. I don't plan to actively pursue either direction, just noting it for future reference.

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




More information about the All-commits mailing list