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

[Duncan Sands]

Hi Oleg,

On 01/09/14 18:46, Oleg Ranevskyy wrote:
> Hi Duncan,
>
> I looked through the IEEE standard and here is what I found:
>
> *6.2 Operations with NaNs*
> /"For an operation with quiet NaN inputs, other than maximum and minimum
> operations, if a floating-point result is to be delivered the result shall be a
> quiet NaN which should be one of the input NaNs"/.
>
> *6.2.3 NaN propagation*
> /"An operation that propagates a NaN operand to its result and has a single NaN
> as an input should produce a NaN with the payload of the input NaN if
> representable in the destination format"./

thanks for finding this out.

>
> Floating point add propagates a NaN. There is no conversion in the context of
> LLVM's fadd. So, if %x in "fadd %x, -0.0" is a NaN, the result is also a NaN
> with the same payload.

Yes, folding "fadd %x, -0.0" to "%x" is correct.  This implies that "fadd undef, 
undef" can be folded to "undef".

>
> As regards "fadd %x, undef", where %x might be a NaN and undef might be chosen
> to be (probably some different) NaN, and a possibility to fold this to a
> constant (NaN), the standard says:
> /"If two or more inputs are NaN, then the payload of the resulting NaN should be
> identical to the payload of one of the input NaNs if representable in the
> destination format. *This standard does not specify which of the input NaNs will
> provide the payload*"/.
>
> Thus, this makes it possible to fold "fadd %x, undef" to a NaN. Is this right?

Yes, I agree.

Ciao, Duncan.

>
> Oleg
>
> On 01.09.2014 10:04, Duncan Sands wrote:
>> 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.
>