<div dir="ltr"><div><div><div>Sure, I'll post clean-ups for LangRef as the first step.<br><br>Make sure everyone's on the same page now: the general rule will be that { fadd, fsub, fmul, fdiv, frem } undef simplification and constant folding will follow IEEE-754 unless stated otherwise. So for fadd:<br><br></div><div>1. fadd %x, undef --> NaN<br></div><div>If the variable operand %x is NaN, the result must be NaN.<br></div><div><br></div><div>2. fadd undef, undef --> undef<br></div><div>Anything is possible.<br><br></div><div>3. fadd C, undef --> undef (where C is not NaN or Inf)<br></div>In the general constant case, the result could be anything as long as constant operand C is not NaN or Inf.<br><br></div>4. fadd NaN, undef --> NaN<br></div>Same reasoning as #1; NaN propagates.<br><br><div><div>5. fadd +/-Inf, undef --> NaN<br><div>If the constant operand is +Inf or -Inf, then the result can only be +Inf or -Inf unless the undef is NaN or the opposite Inf. If the undef is NaN or opposite Inf, the result is NaN, so we choose undef as NaN and propagate NaN. (If some program or known-bits is tracking that the exponent bits are all set, we'll preserve that...)<br></div><div><br></div><div>See IEEE-754 section 7.2 for more rules.<br></div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 4, 2018 at 9:24 AM, Chris Lattner 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 style="word-wrap:break-word;line-break:after-white-space"><div><div class="h5"><br><div><br><blockquote type="cite"><div>On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:</div><br class="m_-7448015606500515469Apple-interchange-newline"><div><div dir="auto">On Mar 3, 2018, at 15:54, Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:<div><br><blockquote type="cite"><div><blockquote type="cite"><div>On Mar 2, 2018, at 8:31 AM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:</div><br class="m_-7448015606500515469Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">Thanks for expanding, Chris. Responses inline.<br><div><br><blockquote type="cite"><div>On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div></blockquote><div><br></div><snip></div><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"> - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations. Either speculation is ok or trapping on SNaN is ok, pick one… (and we already did :) </div></div></blockquote><div><br></div><div>I see the source of confusion now.</div><div><br></div><div>IEEE does not define any operations as trapping on sNaN. It defines operations as raising the invalid flag on sNaN, which is *not a trap* under default exception handling. It is exactly the same as raising the underflow, overflow, inexact, or division-by-zero flag. </div><div><br></div><div>Any llvm <i>instruction</i> necessarily assumes default exception handling—otherwise, we would be using the constrained intrinsics instead. So there’s no reason for sNaN inputs to ever be undef with the llvm instructions. They are just NaNs.</div></div></div></div></blockquote><br></div><div>Ah yes, I completely misunderstood that! Thank you for clarifying. In that case, it seems perfectly reasonable for “fadd undef, 1” to fold to undef, right?</div></blockquote><br></div><div>Yes, indeed.</div></div></div></blockquote></div><br></div></div><div>Great! Can someone please update LangRef so we codify this for the next time I forget? :-)</div><div><br></div><div>-Chris</div><div><br></div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>