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

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

half %a = #x0e02 (0.000366687774?)

half %b = NaN   [based on undef value]

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.


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