[LLVMdev] Float undef value propagation

[Dan Gohman]

On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames <listmail at philipreames.com>wrote:

> 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?


-0.0 is never the result of adding 0.0 to something, so even that isn't
safe (outside of -ffast-math mode)

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131216/81d2ea7b/attachment.html>