similar to: 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

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,

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

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

What I’m saying is that if we have one operand that is not an undef value then that operand might be NaN and if it is then the result must be NaN. So while it may be true that we don’t have a NaN, it is not true that we definitely do not have a NaN in the example. This is analogous to the example in the language reference where it says “%A = or %X, undef” -> “%A = undef” is unsafe because any

Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to

For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter

I'm pretty sure that isn't what nnan is supposed to mean. If the result of nnan math were undefined in the sense of "undef", programs using nnan could have undefined behavior if the result is used in certain ways which would not be undefined for any actual float value (e.g. converting the result to a string), which seems like a surprising result.  And I don't think we

We can do "add %x, undef" => "undef" because for any value of %x, we can always find a value that when added to %x produces any value in the domain of integers. This is not the case with floats since with some inputs, e.g., NaNs, we are not able to produce some values in the domain (e.g., there's no value of %x that makes "fadd NaN, %x" return 42.0). In

So you don’t think sNaNs can just be treated as if they were qNaNs? I understand why we would want to ignore the signaling part of things, but the rules for operating on NaNs are pretty clear and reasonable to implement. The signaling aspect can, I think, be safely ignored when we are in the mode of assuming the default FP environment. As for the distinction between IEEE and LLVM IR, I would

On Mar 1, 2018, at 10:07 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > So you don’t think sNaNs can just be treated as if they were qNaNs? I understand why we would want to ignore the signaling part of things, but the rules for operating on NaNs are pretty clear and reasonable to implement. The signaling aspect can, I think, be safely ignored when we are in the mode of assuming

> On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon <scanon at apple.com> wrote: > > On Mar 3, 2018, at 15:54, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote: > >>> On Mar 2, 2018, at 8:31 AM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote: >>> >>> Thanks for expanding,

Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef

Hi, Thank you for all your helpful comments. To sum up, below is the list of correct folding examples for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of

On 2/28/2018 5:46 PM, Chris Lattner wrote: > On Feb 28, 2018, at 3:29 PM, Kaylor, Andrew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> For the first part of Sanjay’s question, I think the answer is, “Yes, >> we can fold all of these to NaN in the general case.” > > Agreed.  Those IR instructions are undefined on

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

Sure, I'll post clean-ups for LangRef as the first step. Make sure everyone's on the same page now: the general rule will be that { fadd, fsub, fmul, fdiv, frem } undef simplification and constant folding will follow IEEE-754 unless stated otherwise. So for fadd: 1. fadd %x, undef --> NaN If the variable operand %x is NaN, the result must be NaN. 2. fadd undef, undef --> undef

> On Feb 28, 2018, at 6:33 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 2/28/2018 5:46 PM, Chris Lattner wrote: >> On Feb 28, 2018, at 3:29 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of

As far as I know, LLVM does not try very hard to guarantee constant folded NaN payloads that match exactly what the target would generate. —Owen > On Sep 16, 2014, at 10:30 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > > Hi Duncan, > > I reread everything we've discussed so far and would like to pay closer attention to the the ARM's FPSCR register

Hi Duncan, Thank you a lot for your time to provide that great and informative explanation. Now the "undef" logic makes much more sense for me. >> /You are wrong to say that "div undef, %X" is folded to "undef" by InstructionSimplify, it is folded to zero./ My mistake. I meant to say "*f****div* undef, %X" is folded to "undef" (not