[PATCH] Returns NaN for sqrt with negative fp argument

[Matt Arsenault]

On Jun 11, 2014, at 9:30 AM, Owen Anderson <resistor at mac.com> wrote:

> 
> On Jun 11, 2014, at 7:49 AM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
>>> 
>>> Is there any performance advantage of using the explicitly incorrect 0.0?
>> 
>> There's probably no significant difference between 0.0 and NaN, but
>> there could well be between either and undef if it allows future
>> optimisations. If we make any change here, it should be that one.
> 
> 0.0 is generally a cheaper immediate to materialize than NaN.  Most RISC targets have direct support for materializing a zero, but not for materializing a NaN.
> 
> That said, I agree with Tim that undef is the proper solution.  I suspect the 0.0 result was trying to work around an imagined constraint that sqrt(x) must return a positive value.  However, it’s not clear to me that that is something we really care about.

Could we handle this the same way the cttz intrinsic is handled and add an i1 parameter for the < -0.0 behavior of sqrt? The given reason for having this be undefined is to allow it to be used for a wider variety of architectures’ misbehaving sqrt instructions, but on R600 for example the R600 the sqrt instructions always do “the right thing”


-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/67c18e12/attachment.html>