[llvm-commits] [llvm] r154265 - in /llvm/trunk: lib/CodeGen/SelectionDAG/DAGCombiner.cpp test/CodeGen/ARM/vdiv_combine.ll test/CodeGen/X86/fdiv.ll

[Benjamin Kramer]

On 08.04.2012, at 10:20, Duncan Sands wrote:

> Hi Benjamin,
> 
>>> --- llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (original)
>>> +++ llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Sat Apr  7 15:04:00 2012
>>> @@ -5725,6 +5725,19 @@
>>>   if (N0CFP&&  N1CFP&&  VT != MVT::ppcf128)
>>>     return DAG.getNode(ISD::FDIV, N->getDebugLoc(), VT, N0, N1);
>>> 
>>> +  // fold (fdiv X, c2) ->  fmul X, 1/c2 if there is no precision loss or if
>>> +  // losing precision is acceptable.
>>> +  if (N1CFP&&  VT != MVT::ppcf128) {
>>> +    // Compute the reciprocal 1.0 / c2.
>>> +    APFloat N1APF = N1CFP->getValueAPF();
>>> +    APFloat Recip(N1APF.getSemantics(), 1); // 1.0
>>> +    APFloat::opStatus st = Recip.divide(N1APF, APFloat::rmNearestTiesToEven);
>>> +    // Only do the transform if the reciprocal is not too horrible (eg not NaN).
>>> +    if (st == APFloat::opOK || (st == APFloat::opInexact&&
>>> +                                DAG.getTarget().Options.UnsafeFPMath))
>>> +      return DAG.getNode(ISD::FMUL, N->getDebugLoc(), VT, N0,
>>> +                         DAG.getConstantFP(Recip, VT));
>>> +  }
>> 
>> One thing to keep in mind is that we don't want to turn fdivs into fmuls with a denormal number. Denormals may be disabled on the CPU (ops always return 0.0), in other cases they are just painfully slow.
> 
> how to tell if the reciprocal is denormal?  I don't immediately see an APFloat
> method for that.

I guess it needs a new method, there seems to be no way to check it from the outside :(

> 
>> I have a bad feeling about allowing any reciprocal in safe math mode if the division was exact, this is only safe for powers of two in general (see APFloat::getExactInverse).
> 
> Are you saying that forming 1/c may return opOK rather than opInexact even if
> the division is not exact?  If so, what's the point of the status flags?  That
> said, since the exact version is done at the IR level how about I just remove
> it here?

I'm saying that I doubt that there is a guarantee that if 1/c is exact, x*(1/c) will have the same resulting bits as x/c.

- Ben

> 
> Ciao, Duncan.