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

LLVM does not (today) try to preserve rounding mode or sNaNs.  The only
remaining question is whether we should be trying to preserve NaN payloads.

—Owen

On Aug 29, 2014, at 5:39 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com>
wrote:
> Hi,
> 
> So, the result of "fadd x, -0.0" might have a bit pattern
different from the one of "x" depending on the value of "x"
and the target.
> If I get it right, the result does not necessarily compare equal to
"x" in floating point comparisons.
> Does this mean that folding of the above fadd to "x" in
InstructionSimplify is incorrect?
> 
> Oleg
> 
>>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Oleg,

On 01/09/14 15:42, Oleg Ranevskyy wrote:
> Hi,
>
> Thank you for your comment, Owen.
> My LLVM expertise is certainly not enough to make such decisions yet.
> Duncan, do you have any comments on this or do you know anyone else who can
> decide about preserving NaN payloads?
my take is that the first thing to do is to see what the IEEE standard says 
about NaNs.  Consider for example "fadd x, -0.0".  Does the standard
specify the
exact NaN bit pattern produced as output when a particular NaN x is input?  Or 
does it just say that the output is a NaN?  If the standard doesn't care
exactly
which NaN is output, I think it is reasonable for LLVM to assume it is whatever 
NaN is most convenient for LLVM; in this case that means using x itself as the 
output.

However this approach does implicitly mean that we may end up not folding 
floating point operations completely deterministically: depending on the 
optimization that kicks in, in one case we might fold to NaN A, and in some 
different optimization we might fold the same expression to NaN B.  I think this
is pretty reasonable, but it is something to be aware of.

Ciao, Duncan.

Hi,

Thank you for your comment, Owen.
My LLVM expertise is certainly not enough to make such decisions yet.
Duncan, do you have any comments on this or do you know anyone else who 
can decide about preserving NaN payloads?

Thank you.
Oleg

On 29.08.2014 17:55, Owen Anderson wrote:
> LLVM does not (today) try to preserve rounding mode or sNaNs.  The only
remaining question is whether we should be trying to preserve NaN payloads.
>
> —Owen
>
> On Aug 29, 2014, at 5:39 AM, Oleg Ranevskyy <llvm.mail.list at
gmail.com> wrote:
>
>> Hi,
>>
>> So, the result of "fadd x, -0.0" might have a bit pattern
different from the one of "x" depending on the value of "x"
and the target.
>> If I get it right, the result does not necessarily compare equal to
"x" in floating point comparisons.
>> Does this mean that folding of the above fadd to "x" in
InstructionSimplify is incorrect?
>>
>> Oleg
>>
>>>> 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
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev