[llvm-dev] Why does FPBinOp(X, undef) -> NaN?

[Sanjay Patel via llvm-dev]

For reference, the IR side of this was:
https://reviews.llvm.org/D44308

On Fri, Feb 7, 2020 at 1:01 PM Sanjay Patel <spatel at rotateright.com> wrote:

> For reference, the IR side of this was:
>
> On Fri, Feb 7, 2020 at 12:30 PM Nuno Lopes via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> It's not correct (output of Alive2):
>>
>> define half @fn(half %a) {
>>    %b = fadd half %a, undef
>>    ret half %b
>> }
>> =>
>> define half @fn(half %a) {
>>    ret half undef
>> }
>> Transformation doesn't verify!
>> ERROR: Value mismatch
>>
>> Example:
>> half %a = #x0e02 (0.000366687774?)
>>
>> Source:
>> half %b = NaN   [based on undef value]
>>
>> Target:
>> Source value: NaN
>> Target value: #x8000 (-0.0)
>>
>>
>> Essentially, for some inputs, doing an operation with any value can't
>> produce some value, as the example above shows.
>>
>> Nuno
>>
>>
>>
>> Quoting Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org>:
>>
>> > I came across this comment in SelectionDAG.cpp:
>> >
>> >   case ISD::FADD:
>> >   case ISD::FSUB:
>> >   case ISD::FMUL:
>> >   case ISD::FDIV:
>> >   case ISD::FREM:
>> >     // If both operands are undef, the result is undef. If 1 operand
>> > is undef,
>> >     // the result is NaN. This should match the behavior of the IR
>> optimizer.
>> >
>> > That isn't intuitive to me. I would have expected a binary FP
>> > operation with one undef operand to fold to undef. Does anyone know
>> > the reasoning behind that decision? I don't see the value added in
>> > returning a NaN here.
>> >
>> > Thx,
>> > Cameron
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/b65f1f60/attachment.html>