<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 6, 2018, at 7:23 AM, Sanjay Patel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I need to review the last thread about undef/poison (or someone who knows current status of that can reply), but this would seem to come down to whether undef applies to the entire value or the individual bits?<br class=""></div>Ie, in your example the sign bit will never be set unless all of the exponent bits are also set. Each bit individually is unknown, but taken together we know that some sequences are impossible.<br class=""></div></div></blockquote><div><br class=""></div><div>The “on the ground” reason we made undef be a bit-level concept for integers was specific problems with C bitfields: when initializing a mem2reg’d bitfield, you end up doing or’s into undef values, and those bits have to be defined. </div><div><br class=""></div><div>I’m not aware of a similar concept that makes sense for fp values. We could choose to do fine grain tracking (e.g. so ldexp and friends would work to set the exponent??) but I don’t see any practical reason for doing so.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 5, 2018 at 2:02 PM, Nicolai Hähnle via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05.03.2018 19:27, Sanjay Patel via llvm-dev wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. fadd C, undef --> undef (where C is not NaN or Inf)<br class="">
In the general constant case, the result could be anything as long as constant operand C is not NaN or Inf.<br class="">
</blockquote>
<br class=""></span>
If C is the largest finite positive number, then (fadd C, X) cannot be a finite negative number. So doesn't folding (fadd C, undef) --> undef break the rules?<br class="">
<br class="">
Cheers,<br class="">
Nicolai<br class="">
<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br class="">
4. fadd NaN, undef --> NaN<br class="">
Same reasoning as #1; NaN propagates.<br class="">
<br class="">
5. fadd +/-Inf, undef --> NaN<br class="">
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 class="">
<br class="">
See IEEE-754 section 7.2 for more rules.<br class="">
<br class="">
<br class="">
<br class=""></span><span class="">
On Sun, Mar 4, 2018 at 9:24 AM, Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.or<wbr class="">g</a>>> wrote:<br class="">
<br class="">
<br class="">
<br class="">
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon<br class=""></span><span class="">
<<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a> <mailto:<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a>>> wrote:<br class="">
<br class="">
On Mar 3, 2018, at 15:54, Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank" class="">clattner@nondot.org</a><br class=""></span>
<mailto:<a href="mailto:clattner@nondot.org" target="_blank" class="">clattner@nondot.org</a>>> wrote:<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mar 2, 2018, at 8:31 AM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a><br class=""></span><span class="">
<mailto:<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a>>> wrote:<br class="">
<br class="">
Thanks for expanding, Chris. Responses inline.<br class="">
<br class="">
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev<br class=""></span>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.or<wbr class="">g</a>>> wrote:<br class="">
</blockquote><span class="">
<br class="">
<snip><br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Because LLVM reorders and speculates the instruction forms,<br class="">
and because IEEE defines the corresponding IEEE operations as<br class="">
trapping on SNaNs, it is clear that SNaNs are outside of the<br class="">
domain of these LLVM operations. Either speculation is ok or<br class="">
trapping on SNaN is ok, pick one… (and we already did :) <br class="">
</blockquote>
<br class="">
I see the source of confusion now.<br class="">
<br class="">
IEEE does not define any operations as trapping on sNaN. It<br class="">
defines operations as raising the invalid flag on sNaN, which is<br class="">
*not a trap* under default exception handling. It is exactly the<br class="">
same as raising the underflow, overflow, inexact, or<br class="">
division-by-zero flag.<br class="">
<br class=""></span>
Any llvm /instruction/ necessarily assumes default exception<span class=""><br class="">
handling—otherwise, we would be using the constrained intrinsics<br class="">
instead. So there’s no reason for sNaN inputs to ever be undef<br class="">
with the llvm instructions. They are just NaNs.<br class="">
</span></blockquote><span class="">
<br class="">
Ah yes, I completely misunderstood that! Thank you for<br class="">
clarifying. In that case, it seems perfectly reasonable for<br class="">
“fadd undef, 1” to fold to undef, right?<br class="">
</span></blockquote>
<br class="">
Yes, indeed.<br class="">
</blockquote><span class="">
<br class="">
Great! Can someone please update LangRef so we codify this for the<br class="">
next time I forget? :-)<br class="">
<br class="">
-Chris<br class="">
<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class=""></span>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.or<wbr class="">g</a>><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin<wbr class="">/mailman/listinfo/llvm-dev</a>><span class=""><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class="">
</span></blockquote><span class="HOEnZb"><font color="#888888" class="">
<br class="">
<br class="">
-- <br class="">
Lerne, wie die Welt wirklich ist,<br class="">
Aber vergiss niemals, wie sie sein sollte.</font></span><div class="HOEnZb"><div class="h5"><br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>