summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2018-01-08 15:05:34 +0000
committerSanjay Patel <spatel@rotateright.com>2018-01-08 15:05:34 +0000
commit31b4b76f99e1b8f10724e6b64f36b8a8c83db768 (patch)
tree6c3fb67a4142b95f1fe5c2d1ed8aad88a80aef97 /clang/lib/Frontend/CompilerInvocation.cpp
parent18b6b2f994f229b866efe93bfd812eff8ce77dfb (diff)
downloadbcm5719-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
OpenPOWER on IntegriCloud