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

> On Aug 27, 2014, at 6:34 AM, Duncan Sands <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.

—Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140827/0d160d6c/attachment.html>

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.

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