diff options
author | Sanjay Patel <spatel@rotateright.com> | 2018-01-08 15:05:34 +0000 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2018-01-08 15:05:34 +0000 |
commit | 31b4b76f99e1b8f10724e6b64f36b8a8c83db768 (patch) | |
tree | 6c3fb67a4142b95f1fe5c2d1ed8aad88a80aef97 /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | 18b6b2f994f229b866efe93bfd812eff8ce77dfb (diff) | |
download | bcm5719-llvm-31b4b76f99e1b8f10724e6b64f36b8a8c83db768.tar.gz bcm5719-llvm-31b4b76f99e1b8f10724e6b64f36b8a8c83db768.zip |
[InstCombine] fold min/max tree with common operand (PR35717)
There is precedence for factorization transforms in instcombine for FP ops with fast-math.
We also have similar logic in foldSPFofSPF().
It would take more work to add this to reassociate because that's specialized for binops,
and min/max are not binops (or even single instructions). Also, I don't have evidence that
larger min/max trees than this exist in real code, but if we find that's true, we might
want to reorganize where/how we do this optimization.
In the motivating example from https://bugs.llvm.org/show_bug.cgi?id=35717 , we have:
int test(int xc, int xm, int xy) {
int xk;
if (xc < xm)
xk = xc < xy ? xc : xy;
else
xk = xm < xy ? xm : xy;
return xk;
}
This patch solves that problem because we recognize more min/max patterns after rL321672
https://rise4fun.com/Alive/Qjne
https://rise4fun.com/Alive/3yg
Differential Revision: https://reviews.llvm.org/D41603
llvm-svn: 321998
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions