aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineSink.cpp
diff options
context:
space:
mode:
authorNikita Popov <npopov@redhat.com>2022-02-22 17:53:14 +0100
committerNikita Popov <npopov@redhat.com>2022-03-02 16:43:33 +0100
commit61580d0949fd3465f53c71f5a8f304d4722a38fb (patch)
treed25a68c5a7a4be92dc211d7c0f53de4fb20d792f /llvm/lib/CodeGen/MachineSink.cpp
parent5cce97d61e18e49033954793f4bc28906c75a305 (diff)
downloadllvm-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