llvm dev - Aug 2014 - [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef

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

Hi Stephen,
>> 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.
because you get a trap?
> 	(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).
What do you get in this case?
> 	(c) x is +0.0 and the rounding mode is round down.
So far rounding modes were always ignored in LLVM AFAIK.

Note that LLVM folds "fadd x, -0.0" to x (in InstructionSimplify),
which made me
think of exploiting this for the undef case.

Ciao, Duncan.

> On Aug 28, 2014, at 10:58 AM, Duncan Sands <duncan.sands at
deepbluecap.com> wrote:
> 
> Hi Stephen,
> 
>>> 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.
> 
> because you get a trap?
Because you either get a trap (if the invalid exception is unmasked), or the
invalid flag is set and the result is a quiet NaN (much more common).
>> 	(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).
> 
> What do you get in this case?
A NaN whose “payload” (i.e. the bits in what would be the significand field of a
normal number) may be different from those of the input NaN.
>> 	(c) x is +0.0 and the rounding mode is round down.
> 
> So far rounding modes were always ignored in LLVM AFAIK.
I believe you’re right about this, but it would be nice to not paint ourselves
into a corner w.r.t. rounding modes.

– Steve