similar to: [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef

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

Duncan, > Hi Oleg, > >> >> /This is either a mistake, or a decision that in LLVM IR snans >> are always >> considered to be signalling. / >> Yes, this seems to be an agreement to treat "undef" as a SNaN for >> "fdiv". > > "undef" is whatever bit pattern you want it to be, i.e. the compiler > can assume it is any

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

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

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

> On Aug 28, 2014, at 10:58 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > > Hi Stephen, > >>> In the case of fadd, given that "fadd x, -0.0" is always equal to x (same bit pattern), then "fadd x, undef" can be folded to "x" (currently it is folded to undef, which is wrong). This implies that it is correct to fold "fadd

LLVM does not (today) try to preserve rounding mode or sNaNs. The only remaining question is whether we should be trying to preserve NaN payloads. —Owen On Aug 29, 2014, at 5:39 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > Hi, > > So, the result of "fadd x, -0.0" might have a bit pattern different from the one of "x" depending on the value of

> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > > I think you should try to get LLVM floating point experts involved, to find out their opinion about whether LLVM should really assume that snans always trap. > > If they think it is fine to assume trapping, then you can fold any floating point operation with an "undef" operand

On Aug 28, 2014, at 3:03 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > Hi Owen, > > On 27/08/14 19:06, Owen Anderson wrote: >> >>> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com >>> <mailto:duncan.sands at deepbluecap.com>> wrote: >>> >>> I think you should try to get LLVM floating

Hi Oleg, On 01/09/14 18:46, Oleg Ranevskyy wrote: > Hi Duncan, > > I looked through the IEEE standard and here is what I found: > > *6.2 Operations with NaNs* > /"For an operation with quiet NaN inputs, other than maximum and minimum > operations, if a floating-point result is to be delivered the result shall be a > quiet NaN which should be one of the input

Hi Oleg, On 01/09/14 15:42, Oleg Ranevskyy wrote: > Hi, > > Thank you for your comment, Owen. > My LLVM expertise is certainly not enough to make such decisions yet. > Duncan, do you have any comments on this or do you know anyone else who can > decide about preserving NaN payloads? my take is that the first thing to do is to see what the IEEE standard says about NaNs.

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

> 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

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

%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

Hello, The LLVM IR opcodes Add, Sub, and Mul have been each split into two. Add, Sub, and Mul now only handle integer types, and three new opcodes, FAdd, FSub, and FMul now handle floating-point types. The main LLVM APIs are currently preserving backwards compatibility, transparently mapping integer opcodes to corresponding floating-point opcodes when the operands have floating-point types.

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

On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: >> The LLVM IR opcodes Add, Sub, and Mul have been each split into >> two. Add, Sub, and Mul now only handle integer types, and three >> new opcodes, FAdd, FSub, and FMul now handle floating-point types. > > Dan, > > Wondering the reason why there is no FDiv ? FDiv already exists; div was split quite a while ago. Dan

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,