<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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.<div><br></div><div>-Jim<br><div><br><div><blockquote type="cite"><div>On Aug 8, 2014, at 10:49 AM, Owen Anderson <<a href="mailto:resistor@mac.com">resistor@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>As another data point, every GPU I’m aware of directly supports fabs and fneg operations.</div><div><br></div>I would support a proposal to move fabs and fneg either to intrinsics or instructions, and remove the current practice of using fsub.<div><br></div><div>—Owen</div><div><br></div><div><div><div>On Aug 8, 2014, at 8:22 AM, David Jones <<a href="mailto:djones@xtreme-eda.com">djones@xtreme-eda.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div>Is there any intention of making floating absolute and negate primitive IR instructions?<br><br></div>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.<br>
<br></div>I could change my code to do the bit casting and fiddling, but I wonder: would that be lowered appropriately on all architectures?<br><br></div>A quick survey from my various manuals:<br></div>- m68k has negate and absolute value instructions.<br>
</div>- so does x87<br></div><div>- so does PA-RISC<br></div>- but SPARC does not.<br></div>- and neither does x86 SSE (although bit fiddling might be real cheap here)<br><br></div>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.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 10:36 AM, Stephen Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
– Steve<br>
<div class="HOEnZb"><div class="h5"><br>
On Aug 8, 2014, at 4:34 AM, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br>
<br>
> On 7 August 2014 20:52, Keno Fischer <<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>> wrote:<br>
>> One more update: Since the code generated by the bitcast wasn't ideal<br>
>> and we were afraid to loose vectorization, etc., we ended up going<br>
>> with fsub -0.0, x, which for some reason unlike fsub 0.0, x, seems to<br>
>> be have appropriately at all optimization levels.<br>
><br>
> That's because "fsub 0.0, x" is incorrect for x=+0.0. Took me a while<br>
> to work out why the "obvious" choice didn't work the first time I<br>
> encountered it too.<br>
><br>
> Cheers.<br>
><br>
> Tim.<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></div></div>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></div></div></body></html>