[all-commits] [llvm/llvm-project] 862e35: [InstCombine] preserve signbit semantics of NAN wi...

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 862e35e25a68502433da0a8d0819448ff5745339
      https://github.com/llvm/llvm-project/commit/862e35e25a68502433da0a8d0819448ff5745339
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-12-28 (Wed, 28 Dec 2022)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
    M llvm/test/Transforms/InstCombine/fabs.ll
    M llvm/test/Transforms/InstCombine/fneg-fabs.ll
    M llvm/test/Transforms/InstCombine/fneg.ll

  Log Message:
  -----------
  [InstCombine] preserve signbit semantics of NAN with fold to fabs

As discussed in issue #59279, we want fneg/fabs to conform to the
IEEE-754 spec for signbit operations - quoting from section 5.5.1
of IEEE-754-2008:
"negate(x) copies a floating-point operand x to a destination in
the same format, reversing the sign bit"
"abs(x) copies a floating-point operand x to a destination in the
same format, setting the sign bit to 0 (positive)"
"The operations treat floating-point numbers and NaNs alike."

So we gate this transform with "nnan" in addition to "nsz":
(X > 0.0) ? X : -X --> fabs(X)

Without that restriction, we could have for example:
(+NaN > 0.0) ? +NaN : -NaN --> -NaN
(because an ordered compare with NaN is always false)
That would be different than fabs(+NaN) --> +NaN.

More fabs/fneg patterns demonstrated here:
https://godbolt.org/z/h8ecc659d
(without any FMF, these are correct independently of this patch -
no fabs should be created)

The code change is a one-liner, but we have lots of tests diffs
because there are many variations of the basic pattern.

Differential Revision: https://reviews.llvm.org/D139785