[PATCH] PR16258 - fadd with undef not folded

Duncan Sands baldrick at free.fr
Mon Jun 10 08:50:55 PDT 2013


Hi Stephen, thanks for commenting.

On 10/06/13 17:40, Stephen Canon wrote:
> Comments inline.
>
> On Jun 10, 2013, at 8:03 AM, Duncan Sands <baldrick at free.fr
> <mailto:baldrick at free.fr>> wrote:
>
>> [snip]
>>
>> For example, in fadd X, Y if X is a NaN, is it possible, by varying Y, to get
>> every possible bit pattern for the result?
>
> No; you can only get bit patterns that encode NaN values.
>
>> Alternatively, is there a bit pattern that would cause the fadd to trap?
>
> Not without additional assumptions of the fp environment.
>
>> Same question for every other possible value for X.  If for every X, one of
>> the answers is "yes" then it is OK to fold "fadd X, undef" to "undef",
>> otherwise it is not OK.  Because folding to undef means every possible bit
>> pattern for the result can occur.  If it is not OK, it might still be OK with
>> fast-math since we can ignore NaN's and some other oddities.

it might be OK to fold a fast-math fadd with undef to undef thanks to the
following kind of reasoning: in
   fadd fast X, undef
the "fast" attribute promises in particular that no operand is NaN.  But we
can choose the undef value to be NaN if we like.  Thus we can arrange for the
promise to be broken, so we can attribute any value we like to the fadd.  The
dubious part is the "so we can..." - what are the consequences of breaking the
"fast" promise allowed to be?

>
> For nearly every fp value X, there are *many* values of Z such that no Y
> satisfies X + Y = Z.  (Any Z smaller in magnitude than (magnitude of
> X)/2**(significand bits) suffices).  It sounds like the definition of undef
> might be overly restrictive for floating-point optimization?
>
>> Another way to get undef is if there is some bit pattern for Y that the IEEE
>> standard doesn't give a meaning to, in which case we can imagine that the undef
>> was this bit pattern and then we can assign any value we like to the fadd.
>
> All IEEE-754 bit patterns have specified meanings.
>
>> 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?

Ciao, Duncan.



More information about the llvm-commits mailing list