<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/16/13 1:19 PM, Dan Gohman wrote:<br>
</div>
<blockquote
cite="mid:CAF4K+2hn=qLycSY=cHGs2an5Lrt5uCcEmyjPLFJx7VgLg6dVag@mail.gmail.com"
type="cite">
<div dir="ltr">On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames <span
dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a><br>
</div>
<div class="im">
<mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank">listmail@philipreames.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank">listmail@philipreames.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"></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>
</div>
</div>
</div>
</div>
</blockquote>
Dan, thank you for the clarification. Your responses have been very
helpful in understanding corner cases.<br>
<br>
I think that we've identified a couple of transformations which
would be worthwhile adding to SimplifyFAddInst. Would you agree?
Here are the cases I'm considering:<br>
NaN + any == NaN<br>
undef + any == NaN (since undef can be NaN, can not legally
propagate RHS)<br>
<br>
I believe based on our discussion that both of these are correct,
even outside of fast-math. Do you agree?<br>
<br>
I'm happy to prepare a patch, but want to get agreement on the
legality of the transformations first. <br>
<br>
Just to check my understand, the following is NOT legal:<br>
undef + undef = undef (since the output could be -0.0 which is not a
legal outcome for an fadd)<br>
<br>
Yours,<br>
Philip<br>
<br>
</body>
</html>