[LLVMdev] Signed NaNs in APFloat arithmetic

[Jim Grosbach]

I also support moving fneg, at least, to a full IR instruction. fabs I feel less strongly about, but would be fine with as well.

-Jim

> On Aug 8, 2014, at 10:49 AM, Owen Anderson <resistor at mac.com> wrote:
> 
> As another data point, every GPU I’m aware of directly supports fabs and fneg operations.
> 
> I would support a proposal to move fabs and fneg either to intrinsics or instructions, and remove the current practice of using fsub.
> 
> —Owen
> 
> On Aug 8, 2014, at 8:22 AM, David Jones <djones at xtreme-eda.com> wrote:
> 
>> 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
>> 
>> _______________________________________________
>> 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/25a7d62f/attachment.html>