[LLVMdev] Signed NaNs in APFloat arithmetic

[Sanjay Patel]

Yes, xorpd is an IEEE-754 negate, but as you noted, this is not (if LLVM
starts respecting FP exceptions and rounding modes):

  %fsub = fsub float -0.0, %fabsf


So as suggested, LLVM IR requires an fneg instruction or intrinsic to
preserve the fneg operation in the C source down to the asm.



On Fri, Aug 8, 2014 at 1:06 PM, Stephen Canon <scanon at apple.com> wrote:

>
> On Aug 8, 2014, at 2:59 PM, Sanjay Patel <spatel at rotateright.com> wrote:
>
> FYI, I was looking at the SSE/AVX codegen here:
> http://llvm.org/bugs/show_bug.cgi?id=20578
>
> If LLVM starts caring about FP exceptions, even this won't be possible. Is
> there a way of doing an IEEE-754 fneg in C/C++? Ie, there's no fneg() in
> libm, so any C method we choose could cause an exception, and that's not
> allowed by the IEEE definition of fneg.
>
>
> Huh? XOR[PS|PD] is an IEEE-754 negate( ) on x86; it does not raise any FP
> exceptions.
>
> In C, it’s not specified at present whether –x corresponds to negate( ),
> but the general belief (among IEEE-754 committee members) seems to be that
> it should, and historically clang has mostly tried to behave that way.
>
> On a platform where –x does not correspond to the IEEE-754 negate( )
> operation, but the FP representation is known, you would type-pun to
> integer (via union or memcpy), xor the signbit, and type-pun back to FP to
> get the result.  The only platform I know of where even this isn’t possible
> is i386 under an ABI that returns on the x87 stack, where loading a single-
> or double- sNaN necessarily signals invalid.  Thankfully, the last such
> machine is now … what, 15 years old?
>
> – Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140808/0753dff7/attachment.html>