[all-commits] [llvm/llvm-project] 37ead2: [runtime-unroll] Use incrementing IVs instead of d...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 37ead201e6148f2b079179a71ccbad5af223ce03
      https://github.com/llvm/llvm-project/commit/37ead201e6148f2b079179a71ccbad5af223ce03
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2021-11-12 (Fri, 12 Nov 2021)

  Changed paths:
    M llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp
    M llvm/test/DebugInfo/unrolled-loop-remainder.ll
    M llvm/test/Transforms/LoopUnroll/AArch64/runtime-unroll-generic.ll
    M llvm/test/Transforms/LoopUnroll/ARM/multi-blocks.ll
    M llvm/test/Transforms/LoopUnroll/PowerPC/p8-unrolling-legalize-vectors-inseltpoison.ll
    M llvm/test/Transforms/LoopUnroll/PowerPC/p8-unrolling-legalize-vectors.ll
    M llvm/test/Transforms/LoopUnroll/WebAssembly/basic-unrolling.ll
    M llvm/test/Transforms/LoopUnroll/runtime-loop-at-most-two-exits.ll
    M llvm/test/Transforms/LoopUnroll/runtime-loop-multiexit-dom-verify.ll
    M llvm/test/Transforms/LoopUnroll/runtime-loop-multiple-exits.ll
    M llvm/test/Transforms/LoopUnroll/runtime-loop.ll
    M llvm/test/Transforms/LoopUnroll/runtime-loop5.ll
    M llvm/test/Transforms/LoopUnroll/runtime-multiexit-heuristic.ll
    M llvm/test/Transforms/LoopUnroll/runtime-unroll-assume-no-remainder.ll
    M llvm/test/Transforms/LoopUnroll/runtime-unroll-remainder.ll
    M llvm/test/Transforms/LoopUnrollAndJam/unroll-and-jam.ll
    M llvm/test/Transforms/LoopVectorize/X86/float-induction-x86.ll
    M llvm/test/Transforms/LoopVectorize/X86/gather_scatter.ll
    M llvm/test/Transforms/PhaseOrdering/X86/vdiv.ll

  Log Message:
  -----------
  [runtime-unroll] Use incrementing IVs instead of decrementing ones

This is one of those wonderful "in theory X doesn't matter, but in practice is does" changes. In this particular case, we shift the IVs inserted by the runtime unroller to clamp iteration count of the loops* from decrementing to incrementing.

Why does this matter?  A couple of reasons:
* SCEV doesn't have a native subtract node.  Instead, all subtracts (A - B) are represented as A + -1 * B and drops any flags invalidated by such.  As a result, SCEV is slightly less good at reasoning about edge cases involving decrementing addrecs than incrementing ones.  (You can see this in the inferred flags in some of the test cases.)
* Other parts of the optimizer produce incrementing IVs, and they're common in idiomatic source language.  We do have support for reversing IVs, but in general if we produce one of each, the pair will persist surprisingly far through the optimizer before being coalesced.  (You can see this looking at nearby phis in the test cases.)

Note that if the hardware prefers decrementing (i.e. zero tested) loops, LSR should convert back immediately before codegen.

* Mostly irrelevant detail: The main loop of the prolog case is handled independently and will simple use the original IV with a changed start value.  We could in theory use this scheme for all iteration clamping, but that's a larger and more invasive change.