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>
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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140808/45c54f1c/attachment.html>
On Fri, 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.AFAIK, SPARC has absolute and negation instructions (fabss, fnegs) and SPARCv9 has fabsd and fnegd instructions for double precision floating points.> - 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 >
> 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
> I would support a proposal to move fabs and fneg either to intrinsics or > instructions, and remove the current practice of using fsub.Me too (I'd probably favour fneg as an instruction, but perhaps not fabs; though that may be my C++ background showing). Just because we *can* use bitwise ops, doesn't mean it's a good idea (we could eliminate all bitwise ops in terms of nand if we were feeling evil enough). Cheers. Tim.
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>
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>