<div dir="ltr"><div>I've proposed to replace the related fabs() instcombine as a DAG combine:<br><a href="http://reviews.llvm.org/D19391">http://reviews.llvm.org/D19391</a><br><br></div>I still think we should specify what the default FP model is for LLVM, but this patch will hopefully sidestep failures for denorm-as-zero targets introduced by the earlier fabs() patch.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 12, 2016 at 10:33 AM, Daniel Sanders via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-GB">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I'm just talking about the IEEE754-2008 case in my previous email. You mentioned that your target uses arithmetic negation which isn't permitted by IEEE754-2008. For arithmetic
 negation, the optimization is definitely unsafe.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US"> <a href="mailto:fglaser@apple.com" target="_blank">fglaser@apple.com</a> [mailto:<a href="mailto:fglaser@apple.com" target="_blank">fglaser@apple.com</a>]
<b>On Behalf Of </b><a href="mailto:escha@apple.com" target="_blank">escha@apple.com</a><br>
<b>Sent:</b> 12 April 2016 17:24<span class=""><br>
<b>To:</b> Daniel Sanders<br>
<b>Cc:</b> Alex Rosenberg; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Carlos Liam<br>
<b>Subject:</b> Re: [llvm-dev] Implementing a proposed InstCombine optimization<u></u><u></u></span></span></p>
</div>
</div><span class="">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Keep in mind we had a real GLSL conformance test fail because of exactly this sort of “optimization” (using float operations to perform non-destructive operations on values that are actually integers).<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">—escha<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 12, 2016, at 9:18 AM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">Daniel.Sanders@imgtec.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Good point. The same argument seems to apply to copy() too so I suppose it depends how strict we want to be about it.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><u></u><u></u></p>
</div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US">From:</span></b><span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US"> </span></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US"><a href="mailto:fglaser@apple.com" target="_blank">fglaser@apple.com</a>
 [<a href="mailto:fglaser@apple.com" target="_blank">mailto:fglaser@apple.com</a>]<span> </span><b>On Behalf Of<span> </span></b><a href="mailto:escha@apple.com" target="_blank">escha@apple.com</a><br>
<b>Sent:</b><span> </span>11 April 2016 20:55<br>
<b>To:</b><span> </span>Daniel Sanders<br>
<b>Cc:</b><span> </span>Alex Rosenberg; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Carlos Liam<br>
<b>Subject:</b><span> </span>Re: [llvm-dev] Implementing a proposed InstCombine optimization</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Apr 11, 2016, at 4:23 AM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank"><span style="color:purple">Daniel.Sanders@imgtec.com</span></a>> wrote:<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours)<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification.<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I did some digging into IEEE-754 and it seems like this is actually not even safe on fully conformant IEEE-754-2008 platforms.<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times","serif"">5.5.1 Sign bit operations</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times","serif"">5.5.1.0 Implementations shall provide the following homogeneous quiet-computational sign bit operations for all supported arithmetic formats; they only affect the sign bit. The operations treat
 floating-point numbers and NaNs alike, and signal no exception. These operations may propagate non-canonical encodings.</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times","serif""> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times","serif"">copy(x) copies a floating-point operand x to a destination in the same format, with no change to the sign bit. </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times","serif"">negate(x) copies a floating-point operand x to a destination in the same format, reversing the sign bit. negate(x) is not the same as subtraction(0, x) (see 6.3).</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times","serif""> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Note the MAY. fneg is required to flip the top bit even if the input is a NaN. But fneg is not required to maintain the other bits. If the input is a non-canonical NaN, the fneg MAY canonicalize it. In fact, even the ‘copy’ MAY canonicalize
 it. (it also MAY choose to not canonicalize it)<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Thus, if the integer being fneg’d is a non-canonical NaN, fneg MAY modify bits other than the top bit.<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">—escha<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</span></div>
</div>
</div>

<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>