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

[Nuno Lopes via llvm-dev]

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