[PATCH] Returns NaN for sqrt with negative fp argument

[Jiangning Liu]

Tim,

2014-06-10 19:01 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:

> > I think now I understand this a little bit. Following LLVM IR spec, when
> > using -ffast-math, -menable-no-nans are -menable-unsafe-fp-math enabled,
> and
> > this sounds reasonable to retain defined/stable/safe behavior, so we
> can't
> > return NaN, then 0.0 is a choice.
>
> I think we probably *could* return a NaN, other phases would just be
> perfectly entitled to assume we hadn't. Which makes it a not
> particularly useful thing to return.
>
> 0.0 probably isn't too bad either though; the advantage of "undef" is
> that it looks dodgy when scanning through IR so might make tracking
> down bugs easier.
>

If the "undef" you are talking about is the one in LLVM IR, I think it is
not OK, because undef means an undefined value, and for well-defined
program, this undef shouldn't affect semantic. But for the case like
sqrt(-2.01), the original C code is trying to use NaN, which is defined
value (if we ignore errono) to indicate the number is invalid state. For
example, for LLVM IR undef, if we change it to be fixed number (e.g. 0) for
shuffle vector mask, the program logic should retain the same, but for the
case of using sqrt(-2.01) to define NaN in C, we can't change it to be a
fixed number, and the program would fail otherwise.

Anyway, I see a lot of discussions on internet saying fast-math implies no
checks for NaN, If users' code logic depends on NaN, fast-math should just
not work.

Another interesting finding is gcc aarc64 and gcc x86 behave differently
for -ffast-math. For gcc x86, fp zero is being used, but gcc aarch64 is
either keeping sqrt lib call or using sqrt instruction. I would say gcc
aarch64 behaves unexpectedly, but I couldn't simply say it is incorrect for
fast-math. Or maybe the fp zero return for sqrt(-2.01) came from gcc x86
behavior originally?

Thanks,
-Jiangning


>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140611/9930e30a/attachment.html>