OSDN Git Service

[DAGCombiner] reassociate reciprocal sqrt expression to eliminate FP division
authorSanjay Patel <spatel@rotateright.com>
Mon, 6 Jul 2020 22:03:55 +0000 (18:03 -0400)
committerSanjay Patel <spatel@rotateright.com>
Mon, 6 Jul 2020 23:12:21 +0000 (19:12 -0400)
commitea71ba11ab1187af03a790dc20967ddd62f68bfe
tree1da086fd66de7b65f0a4c902838bef883a821695
parent4029f8ede42f69f5fb5affb3eb008e03d448f407
[DAGCombiner] reassociate reciprocal sqrt expression to eliminate FP division

X / (fabs(A) * sqrt(Z)) --> X / sqrt(A*A*Z) --> X * rsqrt(A*A*Z)

In the motivating case from PR46406:
https://bugs.llvm.org/show_bug.cgi?id=46406
...this is restoring the sequence that was originally in the source code.
We extracted a term from within the sqrt because we do not know in
instcombine whether a target will expand a sqrt call.
Note: we could say that the transform in IR should be restricted, but
that would not solve the problem if the source was originally in the
pattern shown here.

This is a gray area for fast-math-flag requirements. I think we should at
least check fast-math-flags on the fdiv and fmul because I view this
transform as 2 pieces: reassociate the fmul operands and form reciprocal
from the fdiv (as with the existing transform). We could argue that the
sqrt also needs FMF, but that was not required before, so we should change
that in a follow-up patch if that seems better.

We don't currently have a way to check that the target will produce a sqrt
or recip estimate without actually creating nodes (the APIs are SDValue
getSqrtEstimate() and SDValue getRecipEstimate()), so we clean up
speculatively created nodes if we are not able to create an estimate.
The x86 test with doubles verifies that we are not changing a test with
no estimate sequence.

Differential Revision: https://reviews.llvm.org/D82716
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
llvm/test/CodeGen/X86/sqrt-fastmath.ll