[LLVMdev] Signed NaNs in APFloat arithmetic

David Jones djones at xtreme-eda.com
Fri Aug 8 08:22:14 PDT 2014


Is there any intention of making floating absolute and negate primitive IR
instructions?

I ask because only a few days ago I was also faced with the task of
implementing negate in my compiler, and finding no suitable IR instruction,
simply subtracted from zero. But this is wrong.

I could change my code to do the bit casting and fiddling, but I wonder:
would that be lowered appropriately on all architectures?

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)

On some of the architectures, moving a value from a floating-point register
to integer and back could impact performance, so it pays to use the
processor's native instructions for negation and absolute value if they
exist.



On Fri, Aug 8, 2014 at 10:36 AM, Stephen Canon <scanon at apple.com> wrote:

> Worth noting that –0.0 – x isn't actually correct either, since it fails
> to flip the sign of –0 if the rounding mode is round toward negative (for
> platforms that support IEEE-754 rounding modes), and it raises invalid if x
> is a signaling NaN.  As Owen noted, FP negation really "ought" to be
> treated as a bitwise operation, rather than mapped into arithmetic.
>
> – Steve
>
> On Aug 8, 2014, at 4:34 AM, Tim Northover <t.p.northover at gmail.com> wrote:
>
> > On 7 August 2014 20:52, Keno Fischer <kfischer at college.harvard.edu>
> wrote:
> >> One more update: Since the code generated by the bitcast wasn't ideal
> >> and we were afraid to loose vectorization, etc., we ended up going
> >> with fsub -0.0, x, which for some reason unlike fsub 0.0, x, seems to
> >> be have appropriately at all optimization levels.
> >
> > That's because "fsub 0.0, x" is incorrect for x=+0.0. Took me a while
> > to work out why the "obvious" choice didn't work the first time I
> > encountered it too.
> >
> > Cheers.
> >
> > Tim.
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> 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/d8ffb9b5/attachment.html>


More information about the llvm-dev mailing list