[all-commits] [llvm/llvm-project] d9e93e: [X86][CodeGenPrepare] Try to reuse IV's incremente...

[max-azul via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d9e93e8e57fe63babc319cbaf84f1afeccb83696
      https://github.com/llvm/llvm-project/commit/d9e93e8e57fe63babc319cbaf84f1afeccb83696
  Author: Max Kazantsev <mkazantsev at azul.com>
  Date:   2021-03-04 (Thu, 04 Mar 2021)

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

  Log Message:
  -----------
  [X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1

While optimizing the memory instruction, we sometimes need to add
offset to the value of `IV`. We could avoid doing so if the `IV.next` is
already defined at the point of interest. In this case, we may get two
possible advantages from this:

- If the `IV` step happens to match with the offset, we don't need to add
  the offset at all;
- We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping
  and it will lead to better register allocation. Even if the overlap will preserve,
  we are not introducing a new overlap, so it should be a neutral transform (Disabled
  this patch, will come with follow-up).

Currently I've only added support for IVs that get decremented using `usub`
intrinsic. We could also support `AddInstr`, however there is some weird
interaction with some other transform that may lead to infinite compilation
in this case (seems like same transform is done and undone over and over).
I need to investigate why it happens, but generally we could do that too.

The first part only handles case where this reuse fully elimiates the offset.

Differential Revision: https://reviews.llvm.org/D96399
Reviewed By: reames