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

Kaylor, Andrew via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 28 12:18:46 PST 2018


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<mailto: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/4b53eb22/attachment.html>


More information about the llvm-dev mailing list