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

[Cameron McInally via llvm-dev]

On Fri, Feb 7, 2020 at 12:29 PM Nuno Lopes <nunoplopes at sapo.pt> 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.

Ok, I can buy that. We're picking NaN for the value of the undef
operand since the result will always be a NaN.

So a few lines below this, we have something similar for integer operations:

    case ISD::ADD:
    case ISD::SUB:
    case ISD::UDIV:
    case ISD::SDIV:
    case ISD::UREM:
    case ISD::SREM:
      return getUNDEF(VT);       // fold op(arg1, undef) -> undef

What's the reasoning behind folding to undef here? Would that fall
into the same "any value can't produce some value" bin?