[all-commits] [llvm/llvm-project] c9e8c9: [InstCombine] fold fmul/fdiv with fabs operands

[RotateRight via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: c9e8c9e3ea2681dc18dd3a2d43d6aa8f37252649
      https://github.com/llvm/llvm-project/commit/c9e8c9e3ea2681dc18dd3a2d43d6aa8f37252649
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2020-06-25 (Thu, 25 Jun 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineInternal.h
    M llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp
    M llvm/test/Transforms/InstCombine/fdiv.ll
    M llvm/test/Transforms/InstCombine/fmul.ll

  Log Message:
  -----------
  [InstCombine] fold fmul/fdiv with fabs operands

fabs(X) * fabs(Y) --> fabs(X * Y)
fabs(X) / fabs(Y) --> fabs(X / Y)

If both operands of fmul/fdiv are positive, then the result must be positive.

There's a NAN corner-case that prevents removing the more specific fold just
above this one:
fabs(X) * fabs(X) -> X * X
That fold works even with NAN because the sign-bit result of the multiply is
not specified if X is NAN.

We can't remove that and use the more general fold that is proposed here
because once we convert to this:
fabs (X * X)
...it is not legal to simplify the 'fabs' out of that expression when X is NAN.
That's because fabs() guarantees that the sign-bit is always cleared - even
for NAN values.

So this patch has the potential to lose information, but it seems unlikely if
we do the more specific fold ahead of this one.

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