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>