On Dec 12, 2013, at 4:57 PM, Philip Reames <listmail at philipreames.com> wrote:> undef + any == NaN (since undef can be NaN) or undef + any (since undef could be zero)undef + non-NaN is still undef. The compiler is free to choose any value of the type it wishes when simplifying an undef expression. The important point is that it still has to be a value of that type. Hence, predicates that are true for any choice of value must still be respected. This is the case for NaN + undef == NaN: while the compiler is free to choose any value for the undef, there is no such value for which the result is not NaN. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131212/746c716f/attachment.html>
On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com> wrote:> > On Dec 12, 2013, at 4:57 PM, Philip Reames <listmail at philipreames.com> > wrote: > > undef + any == NaN (since undef can be NaN) or undef + any (since undef > could be zero) > > > undef + non-NaN is still undef. The compiler is free to choose any value > of the type it wishes when simplifying an undef expression. The important > point is that it still has to be a value *of that type. *Hence, > predicates that are true for *any* choice of value must still be > respected. This is the case for NaN + undef == NaN: while the compiler is > free to choose any value for the undef, there is no such value for which > the result is not NaN. >undef + non-NaN is not undef. This is because while you can pick any value for the original undef, if you leave an undef behind, you can't control what someone else might pick for it. There are floating-point values which cannot be the result of undef + non-NaN for many values of non-NaN, so the result of undef + non-Nan is not an unconstrained undef. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131214/57294d83/attachment.html>
On 12/14/2013 05:18 PM, Dan Gohman wrote:> On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > > On Dec 12, 2013, at 4:57 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > >> undef + any == NaN (since undef can be NaN) or undef + any (since >> undef could be zero) > > undef + non-NaN is still undef. The compiler is free to choose any > value of the type it wishes when simplifying an undef expression. > The important point is that it still has to be a value /of that > type. /Hence, predicates that are true for /any/ choice of value > must still be respected. This is the case for NaN + undef == NaN: > while the compiler is free to choose any value for the undef, there > is no such value for which the result is not NaN. > > > undef + non-NaN is not undef. This is because while you can pick any > value for the original undef, if you leave an undef behind, you can't > control what someone else might pick for it. There are floating-point > values which cannot be the result of undef + non-NaN for many values of > non-NaN, so the result of undef + non-Nan is not an unconstrained undef.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? 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? Philip