[LLVMdev] Float undef value propagation

[Philip Reames]

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