[PATCH] D96399: [X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev created this revision.
mkazantsev added reviewers: spatel, reames, aqjune, greened.
Herald added subscribers: pengfei, hiraditya.
mkazantsev requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

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.

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.


https://reviews.llvm.org/D96399

Files:
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/test/CodeGen/X86/2020_12_02_decrementing_loop.ll
  llvm/test/CodeGen/X86/usub_inc_iv.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D96399.322605.patch
Type: text/x-patch
Size: 6255 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210210/ba1ec29f/attachment.bin>