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

Nuno Lopes via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 7 09:29:42 PST 2020

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

More information about the llvm-dev mailing list