search for: snan's

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

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

...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 SNAN, and that undef > could take on an SNAN value.  Folding 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? -Eli -- Employe...

...ia 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 SNAN, and that undef could take on an SNAN value. Folding 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...

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

...d “exception handling", but this is not what anyone else means by “exception”. Under “default exception handling”—what the llvm instructions assume—it is just setting a sticky bit in a status register that you cannot even read under the assumptions of the llvm instructions, hence operations on sNaN are side-effect free in the LLVM instruction model, just like any other input. > On Mar 2, 2018, at 11:31 AM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for expanding, Chris. Responses inline. > >> On Mar 2, 2018, at 12:32 AM, Chris Lattner...

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

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

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

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

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

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

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

...ituation 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/t...

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

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

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

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 that you could even fold it to an ‘unreachable'. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/ll...

Wait, back up, what? The invalid flag raised by operations on sNaN is no different from any other flag in fenv. There’s nothing sensible about saying that every operation that raises underflow/overflow/inexact is undefined, why are operations on sNaN any different? – Steve > On Feb 28, 2018, at 11:41 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.o...