[all-commits] [llvm/llvm-project] 805115: [LSR] Unify scheduling of existing and inserted ad...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 805115655ee4886d212ef5aebca852cb5ebedc72
      https://github.com/llvm/llvm-project/commit/805115655ee4886d212ef5aebca852cb5ebedc72
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2021-03-03 (Wed, 03 Mar 2021)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
    M llvm/test/Transforms/LoopStrengthReduce/post-increment-insertion.ll

  Log Message:
  -----------
  [LSR] Unify scheduling of existing and inserted addrecs

LSR goes to some lengths to schedule IV increments such that %iv and %iv.next never need to overlap. This is fairly fundamental to LSRs cost model. LSR assumes that an addrec can be represented with a single register. If %iv and %iv.next have to overlap, then that assumption does not hold.

The bug - which this patch is fixing - is that LSR only does this scheduling for IVs which it inserts, but it's cost model assumes the same for existing IVs that it reuses. It will rewrite existing IV users such that the no-overlap property holds, but will not actually reschedule said IV increment.

As you can see from the relatively lack of test updates, this doesn't actually impact codegen much. The main reason for doing it is to make a follow up patch series which improves post-increment use and scheduling easier to follow.

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


  Commit: 99f541734695307f67cada305856cfece4ada88e
      https://github.com/llvm/llvm-project/commit/99f541734695307f67cada305856cfece4ada88e
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2021-03-03 (Wed, 03 Mar 2021)

  Changed paths:
    M llvm/include/llvm/IR/InstrTypes.h
    M llvm/include/llvm/IR/Instructions.h
    M llvm/lib/IR/Instructions.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp

  Log Message:
  -----------
  Sink routine for replacing a operand bundle to CallBase [NFC]

We had equivalent code for both CallInst and InvokeInst, but never cared about the result type.


Compare: https://github.com/llvm/llvm-project/compare/7334b3dc3ea4...99f541734695