[all-commits] [llvm/llvm-project] 4a54e3: [x86] try to replace 0.0 in fcmp with negated operand

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4a54e3eed347ca2bcb840c52c553892101afd252
      https://github.com/llvm/llvm-project/commit/4a54e3eed347ca2bcb840c52c553892101afd252
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-03-31 (Thu, 31 Mar 2022)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/test/CodeGen/X86/fp-stack-compare.ll
    M llvm/test/CodeGen/X86/setcc-combine.ll

  Log Message:
  -----------
  [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