<div dir="ltr">On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/14/2013 05:18 PM, Dan Gohman wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a><br></div><div class="im">
<mailto:<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>>> wrote:<br>
<br>
<br>
    On Dec 12, 2013, at 4:57 PM, Philip Reames<br></div><div class="im">
    <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a> <mailto:<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.<u></u>com</a>>> wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    undef + any == NaN (since undef can be NaN) or undef + any (since<br>
    undef could be zero)<br>
</blockquote>
<br>
    undef + non-NaN is still undef.  The compiler is free to choose any<br>
    value of the type it wishes when simplifying an undef expression.<br></div>
      The important point is that it still has to be a value /of that<br>
    type. /Hence, predicates that are true for /any/ choice of value<div class="im"><br>
    must still be respected.  This is the case for NaN + undef == NaN:<br>
    while the compiler is free to choose any value for the undef, there<br>
    is no such value for which the result is not NaN.<br>
<br>
<br>
undef + non-NaN is not undef. This is because while you can pick any<br>
value for the original undef, if you leave an undef behind, you can't<br>
control what someone else might pick for it. There are floating-point<br>
values which cannot be the result of undef + non-NaN for many values of<br>
non-NaN, so the result of undef + non-Nan is not an unconstrained undef.<br>
</div></blockquote>
This is a very good point.  Does this mean that the only valid transformations of "undef + Constant" are "Constant" (by undef == 0) or "NaN" (by undef == NaN)?  Or are there known easily describible subsets of Constants which allow a more general transform?<br>

<br>
As an example, when Constant == 0, it would appear that propagating the undef is fine.  (I think.)  Are there other cases like this?  Or am I wrong about the legality of this example?<span class="HOEnZb"><font color="#888888"></font></span></blockquote>
<div><br></div><div>-0.0 is never the result of adding 0.0 to something, so even that isn't safe (outside of -ffast-math mode)<br><br></div><div>Dan<br><br></div></div></div></div>