search for: snans

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...

...or expanding, Chris. Responses inline. > On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: <snip> > - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations. Either speculation is ok or trapping on SNaN is ok, pick one… (and we already did :) I see the source of confusion now. IEEE does not define any operations as trapping on sNaN. It defines operations as raising the inva...

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

...these instructions to undef seems reasonable, and it is arguable that you could even fold it to an ‘unreachable'. > > fdiv snan, snan is undefined? As opposed to producing a qnan, as specified by IEEE-754? You’re talking about IEEE, I’m talking about LLVM IR. LLVM IR is undefined on SNaNs. It looks like LangRef isn’t clear about this, the only mention of SNaNs is in this statement: "fdiv is not (currently) defined on SNaN’s.” However, fdiv/fmul/etc are pervasively treated as not having side effects. The intention, and the only sensible definition for them, is that they are...

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 the default FP...

...at 12:32 AM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > <snip> > >> - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations. Either speculation is ok or trapping on SNaN is ok, pick one… (and we already did :) > > I see the source of confusion now. > > IEEE does not define any operations as trapping on sNaN. It defines operations...

...Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> <snip> >>> >>> - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations. Either speculation is ok or trapping on SNaN is ok, pick one… (and we already did :) >> >> I see the source of confusion now. >> >> IEEE does not define any operations as trapping on sNaN. It de...

...lvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> <snip> >>> >>>> - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations. Either speculation is ok or trapping on SNaN is ok, pick one… (and we already did :) >>> >>> I see the source of confusion now. >>> >>> IEEE does not define any operations as trappin...

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 convenien...

...%X, undef" it states: "because the undef is allowed to be an arbitrary value, we are allowed to assume that it could be zero. ****Since a divide by zero has undefined behavior****...". This is not true for floats. >> /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". The question is whether we can make the same assumption for other floating point operations, or "fdiv" needs a correction to prevent folding since sig...

...line. > > On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > <snip> > > - Because LLVM reorders and speculates the instruction forms, and because > IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is > clear that SNaNs are outside of the domain of these LLVM operations. > Either speculation is ok or trapping on SNaN is ok, pick one… (and we > already did :) > > > I see the source of confusion now. > > IEEE does not define any operations as trapping on sNaN. It de...

....org>> wrote: >>>> >>>> <snip> >>>> >>>>>  - Because LLVM reorders and speculates the instruction forms, >>>>> and because IEEE defines the corresponding IEEE operations as >>>>> trapping on SNaNs, it is clear that SNaNs are outside of the >>>>> domain of these LLVM operations.  Either speculation is ok or >>>>> trapping on SNaN is ok, pick one…  (and we already did :) >>>> >>>> I see the source of confusion now. >>>...

%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

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

...gue against adopting them either, because they do make perfect sense. Some notes on how these definitions align with existing architectures of interest: ARMv8: 1. FMIN / FMAX implement the new minimum / maximum exactly. 2. FMINNM / FMAXNM implement minimumNumber / maximumNumber if we can prove no sNaNs are present. If sNaN may be present, we need to canonicalize each argument first. X86: 1. AFAIK there’s no trivial instruction for minimum / maximum, because MINxx / MAXxx return the second argument if either is NaN. So this will look like a compare + min/max + select, I think. 2. The new AVX-512...

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at...

> 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 to "undef". > > If they think it is no good, then the existing folds that use this need to be removed or weakened, though maybe anot...

...>>>>> >>>>> <snip> >>>>> >>>>> - Because LLVM reorders and speculates the instruction forms, >>>>>> and because IEEE defines the corresponding IEEE operations as >>>>>> trapping on SNaNs, it is clear that SNaNs are outside of the >>>>>> domain of these LLVM operations. Either speculation is ok or >>>>>> trapping on SNaN is ok, pick one… (and we already did :) >>>>>> >>>>> >>>>> I see t...

On Feb 28, 2018, at 3:29 PM, Kaylor, Andrew via llvm-dev <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 SNAN, and that undef could take on an SNAN value. Folding these instructions to undef seems reasonable, and it is arguable

...different? – Steve > On Feb 28, 2018, at 11:41 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > However, fdiv/fmul/etc are pervasively treated as not having side effects. The intention, and the only sensible definition for them, is that they are undefined on SNaNs. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180301/b051227f/attachment.html>