[all-commits] [llvm/llvm-project] a6c8e2: [IndVars] Generate zext nneg when locally obvious

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a6c8e27b3a052913a15a13ee0d4ac466c5ab3f92
      https://github.com/llvm/llvm-project/commit/a6c8e27b3a052913a15a13ee0d4ac466c5ab3f92
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-11-03 (Fri, 03 Nov 2023)

  Changed paths:
    M llvm/lib/Transforms/Utils/SimplifyIndVar.cpp
    M llvm/test/Analysis/ScalarEvolution/guards.ll
    M llvm/test/Transforms/IndVarSimplify/X86/pr59615.ll
    M llvm/test/Transforms/IndVarSimplify/post-inc-range.ll
    M llvm/test/Transforms/LoopFlatten/widen-iv2.ll
    M llvm/test/Transforms/LoopFlatten/widen-iv3.ll

  Log Message:
  -----------
  [IndVars] Generate zext nneg when locally obvious

zext nneg was recently added to the IR in #67982.  This patch teaches
SimplifyIndVars to prefer zext nneg over *both* sext and plain zext,
when a local SCEV query indicates the source is non-negative.

The choice to prefer zext nneg over sext looks slightly aggressive
here, but probably isn't so much in practice.  For cases where we'd
"remember" the range fact, instcombine would convert the sext into
a zext nneg anyways.  The only cases where this produces a different
result overall are when SCEV knows a non-local fact, and it doesn't
get materialized into the IR.  Those are exactly the cases where
using zext nneg are most useful.  We do run the risk of e.g. a
missing combine - since we haven't updated most of them yet - but
that seems like a manageable risk.

Note that there are much deeper algorithmic changes we could make
to this code to exploit zext nneg, but this seemed like a reasonable
and low risk starting point.