[PATCH] PR16258 - fadd with undef not folded

[Duncan Sands]

Hi Steve,

>>>>>> If undef can't be achieved, it might still be possible to fold to a NaN
>>>>>> or some other special value.
>>>>>
>>>>> Folding to NaN sounds workable to me.
>>>>
>>>> So if Y is a well-chosen NaN (or will any NaN do?) then fadd X, Y will always
>>>> be equal to Y?  Does the same go for fmul, fsub and fdiv?
>>>
>>> If Y is any NaN, then the result of any IEEE-754 basic operation (add, sub, mul,
>>> div, sqrt, ... ) will be NaN (it will not “be equal to Y", because NaNs compare
>>> unequal to everything).
>>
>> by equal I meant: the same bit pattern.
>
> There’s some subtlety here w.r.t. bit patterns (the result of OP x, y when x and
> y are both NaNs will be a NaN, but the exact bit pattern isn’t pinned down and
> in practice depends on the phase of the moon).  However, NaN bit patterns are
> essentially an implementation detail; I think there’s enough room here that we
> can reasonably fold undef operations to NaN (and as a programmer, I would
> certainly be very happy to get NaN for undef; NaN is a big obvious smoking gun).

there's also the case of
   fadd undef, undef
Can this be folded to undef?  Note that the two undefs aren't correlated, i.e.
for every bit pattern Z, there just needs to exist some X and some Y such that
fadd X, Y has the bit pattern Z.  For example, does fadd Z, 0 always have the
same bit pattern as Z?

Thanks, Duncan.

PS: Same question for fmul etc.