<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="">Thanks for expanding, Chris. Responses inline.<br class=""><div><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><br class=""></div><snip></div><div><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><br class=""></div><div>I see the source of confusion now.</div><div><br class=""></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 class=""></div><div>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><br class=""></div><div>– Steve</div></div></body></html>