Re: Activate -mrecip with -ffast-math?

[Uros Bizjak <ubizjak at gmail dot com>]

tbp wrote:

> For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first
> get an inf from said reciprocal which then turns to a NaN in the NR
> stage but if you correct it by, say, doing a comparison to 0 and a
> 'and'.
> That's what ICC used to do in your back. That's what you'll find page
> 151 of the amdfam10 optimization manual. Because that's a common case.
>
> As far as i can see, there's no such provision in the current patch.
> At the very least provide a mean to look after those NaNs without
> losing sanity, like a way to enforce argument order of
> min/max[ss|ps|pd] without ressorting to inline asm.

But even if sqrt is corrected for 0.0 * inf, there would still be a lot 
of problems with the combinations of NR-enhanced rsqrt and rcp. Consider 
for example:

1.0/sqrt(a/b) alias rsqrt(a/b)

Having a=0, b != 0, the result is inf.

This expression is mathematically equal to sqrt(b/a) and the compiler is 
free to do this optimization. In this case, b*rcp(a) produces NaN due to 
NR of rcp(a) and here we loose.

Let's correct both, rsqrt and rcp NR steps for 0.0, so we have 
NR-rsqrt(0.0) = inf, NR-rcp(0.0) = inf.

Again, sqrt(b/a) will create sqrt(inf) = inf * rsqrt(inf), so NR step 
for rsqrt will hit (0.0 * inf) from the other side. We loose, because 
there is no correction for the case where input operand is infinity.

IMO,  due to limited range of operands for -mrecip pass (inf, -inf); 
where 0.0 is excluded, it should be keept out of -ffast-math. There is 
no point to fix reciprocals only for 0.0, we need to fix both 
conversions for infinity and 0.0, even in -ffast-math.

Uros.