diff options
| author | Sanjay Patel <spatel@rotateright.com> | 2022-03-31 08:21:28 -0400 |
|---|---|---|
| committer | Sanjay Patel <spatel@rotateright.com> | 2022-03-31 09:17:49 -0400 |
| commit | 4a54e3eed347ca2bcb840c52c553892101afd252 (patch) | |
| tree | af713247cb70bfc791ca0b2d6c4acbace9defe9d /llvm/tools/llvm-readobj/llvm-readobj.cpp | |
| parent | ea9cf2dc96c765773ee574a9189d529175a57751 (diff) | |
| download | llvm-4a54e3eed347ca2bcb840c52c553892101afd252.zip llvm-4a54e3eed347ca2bcb840c52c553892101afd252.tar.gz llvm-4a54e3eed347ca2bcb840c52c553892101afd252.tar.bz2 | |
[x86] try to replace 0.0 in fcmp with negated operand
This inverts a fold recently added to IR with:
3491f2f4b033
We can put -bidirectional on the Alive2 examples to show that
the reverse transforms work:
https://alive2.llvm.org/ce/z/8iVQwB
The motivation for the IR change was to improve matching to
'fabs' in IR (see https://github.com/llvm/llvm-project/issues/38828 ),
but it regressed x86 codegen for 'not-quite-fabs' patterns like
(X > -X) ? X : -X.
Ie, when there is no fast-math (nsz), the cmp+select is not a proper
fabs operation, but it does map nicely to the unusual NAN semantics
of MINSS/MAXSS.
I drafted this as a target-independent fold, but it doesn't appear to
help any other targets and seems to cause regressions for SystemZ at
least.
Differential Revision: https://reviews.llvm.org/D122726
Diffstat (limited to 'llvm/tools/llvm-readobj/llvm-readobj.cpp')
0 files changed, 0 insertions, 0 deletions