aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorRoman Lebedev <lebedev.ri@gmail.com>2020-04-21 21:24:36 +0300
committerRoman Lebedev <lebedev.ri@gmail.com>2020-04-21 22:00:23 +0300
commit352fef3f11f5ccb2ddc8e16cecb7302a54721e9f (patch)
tree7b3c1aed4e1bb7333ffc9136c347408f6989a7e6 /clang/lib/Frontend/CompilerInvocation.cpp
parenta13dce1d90cba6c55252dee0a2600eab37ffbc44 (diff)
downloadllvm-352fef3f11f5ccb2ddc8e16cecb7302a54721e9f.zip
llvm-352fef3f11f5ccb2ddc8e16cecb7302a54721e9f.tar.gz
llvm-352fef3f11f5ccb2ddc8e16cecb7302a54721e9f.tar.bz2
[InstCombine] Negator - sink sinkable negations
Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions