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. On Fri, Aug 8, 2014 at 12:29 PM, Stephen Canon <scanon at apple.com> wrote:> > > On Aug 8, 2014, at 11:22 AM, David Jones <djones at xtreme-eda.com> wrote: > > > > A quick survey from my various manuals: > > - m68k has negate and absolute value instructions. > > - so does x87 > > - so does PA-RISC > > - but SPARC does not. > > - and neither does x86 SSE (although bit fiddling might be real cheap > here) > > [V]AND[SS|SD|PS|PD] / [V]ANDN[SS|SD|PS|PD] / [V]OR[SS|SD|PS|PD] is by far > the preferred idiom to perform these operations on SSE/AVX. > > – Steve > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140808/7115c16f/attachment.html>
> 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/f6d0d055/attachment.html>
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>