diff options
author | Nikita Popov <npopov@redhat.com> | 2022-02-22 17:53:14 +0100 |
---|---|---|
committer | Nikita Popov <npopov@redhat.com> | 2022-03-02 16:43:33 +0100 |
commit | 61580d0949fd3465f53c71f5a8f304d4722a38fb (patch) | |
tree | d25a68c5a7a4be92dc211d7c0f53de4fb20d792f /llvm/lib/CodeGen/MachineSink.cpp | |
parent | 5cce97d61e18e49033954793f4bc28906c75a305 (diff) | |
download | llvm-61580d0949fd3465f53c71f5a8f304d4722a38fb.zip llvm-61580d0949fd3465f53c71f5a8f304d4722a38fb.tar.gz llvm-61580d0949fd3465f53c71f5a8f304d4722a38fb.tar.bz2 |
Reapply [InstCombine] Remove one-use limitation from X-Y==0 fold
This is a recommit without changes. I originally reverted this
due to a significant code-size regression on tramp3d-v4, however
further investigation showed that in the tramp3d-v4 case this
change enables additional optimizations (in particular more
jump threading), which happens to reduce the size of a function
just enough to be eligible for inlining at hot callsites, which
results in the code size increase. As such, this was just bad
luck.
-----
This one-use limitation is artificial, we do not increase
instruction count if we perform the fold with multiple uses. The
motivating case is shown in @sub_eq_zero_select, where the one-use
limitation causes us to miss a subsequent select fold.
I believe the backend is pretty good about reusing flag-producing
subs for cmps with same operands, so I think doing this is fine.
Differential Revision: https://reviews.llvm.org/D120337
Diffstat (limited to 'llvm/lib/CodeGen/MachineSink.cpp')
0 files changed, 0 insertions, 0 deletions