diff options
author | Max Kazantsev <mkazantsev@azul.com> | 2021-03-04 12:01:39 +0700 |
---|---|---|
committer | Max Kazantsev <mkazantsev@azul.com> | 2021-03-04 15:22:55 +0700 |
commit | d9e93e8e57fe63babc319cbaf84f1afeccb83696 (patch) | |
tree | 91f17200de741b69e2815310c356d78c5d35433a /lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | |
parent | b15ce2f344ac7845729d2be0a8316b20a32c6292 (diff) | |
download | llvm-d9e93e8e57fe63babc319cbaf84f1afeccb83696.zip llvm-d9e93e8e57fe63babc319cbaf84f1afeccb83696.tar.gz llvm-d9e93e8e57fe63babc319cbaf84f1afeccb83696.tar.bz2 |
[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
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp')
0 files changed, 0 insertions, 0 deletions