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

Sanjay Patel via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 7 10:01:54 PST 2020

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/c91aee23/attachment.html>

More information about the llvm-dev mailing list