[PATCH] PR16258 - fadd with undef not folded

[Stephen Canon]

Comments inline.

On Jun 10, 2013, at 8:03 AM, Duncan Sands <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.

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.

- Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130610/7a69ebf8/attachment.html>