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

[Stephen Canon]

On Aug 28, 2014, at 3:03 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote:

> 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?

fadd x, –0.0 always has the same bit pattern as x, unless:

	(a) x is a signaling NaN on a platform that supports them.
	(b) x is a quiet NaN on a platform that does not propagate NaN payloads (e.g. ARM with "default nan" bit set in fpscr).
	(c) x is +0.0 and the rounding mode is round down.

– Steve