diff options
author | Sanjay Patel <spatel@rotateright.com> | 2020-06-25 11:28:04 -0400 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2020-06-25 11:35:38 -0400 |
commit | c9e8c9e3ea2681dc18dd3a2d43d6aa8f37252649 (patch) | |
tree | f419b83a38b60580d73fcefdf2425264284ba035 /clang/unittests/Tooling/Syntax/TreeTest.cpp | |
parent | b044a8227078823c83c213765f220e502b2346ed (diff) | |
download | llvm-c9e8c9e3ea2681dc18dd3a2d43d6aa8f37252649.zip llvm-c9e8c9e3ea2681dc18dd3a2d43d6aa8f37252649.tar.gz llvm-c9e8c9e3ea2681dc18dd3a2d43d6aa8f37252649.tar.bz2 |
[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
Diffstat (limited to 'clang/unittests/Tooling/Syntax/TreeTest.cpp')
0 files changed, 0 insertions, 0 deletions