(original) (raw)

For reference, the IR side of this was:

On Fri, Feb 7, 2020 at 12:30 PM Nuno Lopes via llvm-dev <llvm-dev@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@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@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev