[LLVMdev] Float undef value propagation

[Philip Reames]

On 12/16/13 1:19 PM, Dan Gohman wrote:
> On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames 
> <listmail at philipreames.com <mailto: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>
>         <mailto: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>
>         <mailto: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, thank you for the clarification.  Your responses have been very 
helpful in understanding corner cases.

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:
NaN + any == NaN
undef + any == NaN (since undef can be NaN, can not legally propagate RHS)

I believe based on our discussion that both of these are correct, even 
outside of fast-math.  Do you agree?

I'm happy to prepare a patch, but want to get agreement on the legality 
of the transformations first.

Just to check my understand, the following is NOT legal:
undef + undef = undef (since the output could be -0.0 which is not a 
legal outcome for an fadd)

Yours,
Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131219/607b566c/attachment.html>