[llvm-dev] how to simplify FP ops with an undef operand?

[Sanjay Patel via llvm-dev]

Correct - NaN is not undef in IR. But we don't have a NaN in this example.
We have its moral equivalent in LLVM - an uninitialized value, undef.

So we're not introducing any extra uncertainty by propagating the undef.
The backend can choose whatever encoding of undef makes sense when lowering?

And yes, I don't know why FP-div-by-zero would ever be UB. I think that
text in the LangRef should be removed regardless of any other outcome here.

On Wed, Feb 28, 2018 at 1:18 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

> Why is NaN “just ‘undef’ in IR”? NaN is a specific value with well-defined
> behavior. I would think that unless the no-NaNs flag is used we need to
> preserve the behavior of NaNs.
>
>
>
> *From:* Sanjay Patel [mailto:spatel at rotateright.com]
> *Sent:* Wednesday, February 28, 2018 12:08 PM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; Nuno Lopes <nunoplopes at sapo.pt>;
> Stephen Canon <scanon at apple.com>; David Majnemer <david.majnemer at gmail.com>;
> John Regehr <regehr at cs.utah.edu>; Sanjoy Das <sanjoy at playingwithpointers.
> com>; Friedman, Eli <efriedma at codeaurora.org>; Matt Arsenault <
> arsenm2 at gmail.com>
> *Subject:* Re: how to simplify FP ops with an undef operand?
>
>
>
> Yes, if %x is a NaN, we should expect that NaN is propagated.
>
> I'm still not sure what to do here. We can take comfort in knowing that
> whatever we do is likely an improvement over the current situation though.
> :)
>
> That's because the code in InstSimplify is inconsistent with the LangRef:
> http://llvm.org/docs/LangRef.html#undefined-values (UB for fdiv by 0?)
>
> ...and both of those are inconsistent with undef handling in SDAG.
>
> Let me propose an alternate interpretation:
>
> 1. The meaning of snan as written in IEEE754-2008 is: "Signaling NaNs
> afford representations for uninitialized variables..."
> 2. That matches our intent with 'undef' here in IR as written in the
> LangRef: "unspecified bit-pattern".
> 3. The current fdiv transform is actually correct (any SNaN UB/trapping
> commentary is irrelevant because we assume exceptions are off by default).
>
> The undef operand represents an uninitialized variable, and the result of
> any FP op with that uninitialized variable is well-defined: it's another
> NaN which is just 'undef' in IR.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Feb 28, 2018 at 11:43 AM, Kaylor, Andrew <andrew.kaylor at intel.com>
> wrote:
>
> I’m not sure the transformation happening with fdiv is correct. If we have
> “%y = fdiv float %x, undef” and %x is a NaN then the result will be NaN for
> any value of the undef, right? So if I understand the undef rules correctly
> (never a certainty) then we can’t safely replace the expression with undef.
> We could, I think, replace it with “%y = %x” though. I think the same is
> true for fadd, fsub, fmul, and frem.
>
>
>
> -Andy
>
>
>
>
>
> %y = fadd float %x, undef
>
>
>
> Can we simplify this?
>
> Currently in IR, we do nothing for fadd/fsub/fmul. For fdiv/frem, we
> propagate undef. The code comment for fdiv/frem says:
> "the undef could be a snan"
>
>
>
> If that's correct, then shouldn't it be the same for fadd/fsub/fmul? But
> this can't be correct because we support targets that don't raise
> exceptions...and even targets that raise exceptions do not trap by default
> on snan?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180228/b17641b8/attachment.html>