[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef

[Duncan Sands]

Hi Owen,

On 27/08/14 19:06, Owen Anderson wrote:
>
>> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com
>> <mailto:duncan.sands at deepbluecap.com>> wrote:
>>
>> I think you should try to get LLVM floating point experts involved, to find
>> out their opinion about whether LLVM should really assume that snans always trap.
>>
>> If they think it is fine to assume trapping, then you can fold any floating
>> point operation with an "undef" operand to "undef".
>>
>> If they think it is no good, then the existing folds that use this need to be
>> removed or weakened, though maybe another argument can be found to justify them.
>
> LLVM is used to target many platforms for which sNaNs do not trap, and indeed
> many platforms that do not have floating point exceptions at all.

thanks for the info.  All of the floating point folds that rely on snans 
trapping should be corrected then.

In the case of fadd, given that "fadd x, -0.0" is always equal to x (same bit 
pattern), then "fadd x, undef" can be folded to "x" (currently it is folded to 
undef, which is wrong).  This implies that it is correct to fold "fadd undef, 
undef" to undef.  Actually is it true that "fadd x, -0.0" always has exactly the 
same bits as x, or does it just compare equal to x when doing floating point 
comparisons?

It would be better to fold "fadd x, undef" to a constant rather than to x, but 
is this possible?  For example, undef could be chosen to be a NaN, in which case 
it is tempting to say that "fadd x, NaN" can be folded to NaN.  The problem is 
that there are lots of NaNs.  Suppose we choose a particular one, wonder-NaN. 
Is it then true that for any x, there exists some y (presumably a NaN) such that 
"fadd x, y" has the same bit pattern as wonder-NaN?

Ciao, Duncan.