[all-commits] [llvm/llvm-project] 34637b: [tests] precommit test for an upcoming change

[Philip Reames via All-commits]

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

  Changed paths:
    M llvm/test/CodeGen/X86/usub_inc_iv.ll

  Log Message:
  -----------
  [tests] precommit test for an upcoming change


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

  Changed paths:
    M llvm/lib/CodeGen/CodeGenPrepare.cpp
    M llvm/test/CodeGen/X86/usub_inc_iv.ll

  Log Message:
  -----------
  [cgp] improve robustness of uadd/usub transforms

LSR prefers to schedule iv increments just before the latch.  The recent 80511565 broadened this to moving increments in the original IR.  This pointed out a robustness problem with the CGP transform.

When we have a use of an induction increment outside of the loop (we canonicalize away from this form, but it happens e.g. unanalyzeable loops) we'd avoid performing the uadd/usub transform.  Interestingly, all of these involve moving the increment closer to it's operands, so there's no concern about dominating all uses.  We can handle that case cheaply, resulting in a more robust transform.


Compare: https://github.com/llvm/llvm-project/compare/79f736c150c5...d6394d86cadf