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.
