<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon <<a href="mailto:scanon@apple.com" class="">scanon@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">On Mar 3, 2018, at 15:54, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<div class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2018, at 8:31 AM, Stephen Canon <<a href="mailto:scanon@apple.com" class="">scanon@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for expanding, Chris. Responses inline.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div></blockquote><div class=""><br class=""></div><snip></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""> - 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 class=""><br class=""></div><div class="">I see the source of confusion now.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Any llvm <i class="">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 class=""></div><div class="">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 class=""></div><div class="">Yes, indeed.</div></div></div></blockquote></div><br class=""><div class="">Great! Can someone please update LangRef so we codify this for the next time I forget? :-)</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>