search for: minnum

...wen Anderson <resistor at mac.com> wrote: > I’d be fine with that proposal. I could even be convinced if we wanted to add a pair of NaN-propagating intrinsics as well, for targets and languages that want those semantics, even if I disagree with them. I do think that, if we are using the minnum/maxnum names, we should explicitly note that they are equivalent to C’s fmin/fmax, but not std::min/std::max or Java(script)’s min/max. > > —Owen > > >> On Sep 15, 2014, at 12:26 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> >> Given IEEE-754's sway,...

Hi, The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize). Currently according to the LangRef:...

Given IEEE-754's sway, and its saying what it does on this point, but given also the popularity of NaN-propagating min and max, how about a compromise? We add intrinsics following the IEEE-754 semantics, but we also follow IEEE-754 (and ARMv8) in renaming them to minnum and maxnum, to clarify which interpretation these intrinsics are using. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140915/ef59050f/attachment.html>

...radbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 23 July 2018 at 11:56, Arsenault, Matthew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> Hi, >> >> >> The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear >> right now to usefully optimize. There are two problems. First the expected >> behavior for signaling NaNs needs to be clarified. Second, whether the >> returned value is expected to be canonicalized (as if by llvm.canonicalize). >> &...

...'t resolve the semantics. During the dev meeting, a reductions proposal where the operation to be performed was a kind of opcode was discussed, and rejected by the community. I don't believe having many intrinsics would be a problem. > For a min/max reduction, why not just extend @llvm.minnum and @llvm.maxnum? For the same reasons that we don't re-use the other binary operator instructions like add, sub, mul. The vector versions of those are not horizontal operations, they instead produce vector results. > >> We have multiple options for expressing vector predication in r...

...to require the function attribute "no-nans-fp-math" to be set. Just setting instruction flags is not enough. This forces us to give up on fine-grained control of fast-math in the code in order to benefit from this vectorization. How to overcome this? LLVM has intrinsic functions such as `minnum` and `minimum` (`minnan`) that accurately represent the operation. This could permit fine-grained control of fast-math flags, although the vectorizer seems to ignore these intrinsics. Beyond this specific case, it would be nice to be sure when is it ever necessary to set these function attributes,...

On 1 February 2017 at 08:27, Renato Golin <renato.golin at linaro.org> wrote: > Sorry, I meant min/max + reduce, just like above. > > %sum = add <N x float>, <N x float> %a, <N x float> %b > %min = @llvm.minnum(<N x float> %sum) > %red = @llvm.reduce(%min, float %acc) No, this is wrong. I actually meant overriding the max/min intrinsics to take vectors instead of two scalar options. The semantics of those intrinsics is to get a number of parameters and return the max/min on their own type. A...

...n cover all SVE can do, let alone other reductions. Why not simplify this into something like: %sum = add <N x float>, <N x float> %a, <N x float> %b %red = @llvm.reduce(%sum, float %acc) or %fast_red = @llvm.reduce(%sum) For a min/max reduction, why not just extend @llvm.minnum and @llvm.maxnum? > We have multiple options for expressing vector predication in reductions: > 1. The first is to simply add a predicate operand to the intrinsics, and require that targets without predication explicitly pattern match for an all-true predicate in order to select har...

… actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]: minNum(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN. Otherwise, it is either x or y (this means results might differ among implementations). So I think your proposed semantics are perfectly reasonable. – Steve > On Aug 14, 2014, at 10:55 AM, Steve Can...

Hi, It’s been a few years now since I added some intrinsics for doing vector reductions. We’ve been using them exclusively on AArch64, and I’ve seen some traffic a while ago on list for other targets too. Sander did some work last year to refine the semantics after some discussion. Are we at the point where we can drop the “experimental” from the name? IMO all target should begin to transition

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

...st-math flags, or if this is an && condition that should be an > || condition. > > > This forces us to give up on fine-grained control of fast-math in the code > in order to benefit from this vectorization. > > How to overcome this? LLVM has intrinsic functions such as `minnum` and > `minimum` (`minnan`) that accurately represent the operation. This could > permit fine-grained control of fast-math flags, although the vectorizer > seems to ignore these intrinsics. > > Beyond this specific case, it would be nice to be sure when is it ever > necessary to s...

...Cc: llvm-commits; LLVM Developers Mailing List > Subject: Re: [LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics > > … actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]: > > minNum(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN. Otherwise, it is either x or y (this means results might differ among implementations). > > So I think your proposed semantics are perfectly reasonable. > > – Steve > > On Aug 14,...

...t should be an >>> || condition. >>> >>> >>> This forces us to give up on fine-grained control of fast-math in the >>> code in order to benefit from this vectorization. >>> >>> How to overcome this? LLVM has intrinsic functions such as `minnum` and >>> `minimum` (`minnan`) that accurately represent the operation. This could >>> permit fine-grained control of fast-math flags, although the vectorizer >>> seems to ignore these intrinsics. >>> >>> Beyond this specific case, it would be nice to be...

...would be expensive on many systems, and is not necessary to support common library functions. The intrinsics can replace calls to the C and OpenCL library functions. The intrinsics can be implemented as calls to the C or OpenCL library functions. They can also be implemented by IEEE 754 maxNum()/minNum() operations (but not vice versa). The intrinsics are not equivalent to an fcmp/select sequence. -- Kevin Schoedel, Software Developer, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580 Disclaimer: the above just might possibly contain a statement that is not an offici...

On Dec 5, 2012, at 8:26 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > I have been working on a patch to add support for max/min reductions in LoopVectorize. One of the comments that came up in review is that the implementation could be simplified (and less fragile) if max and min intrinsics were recognized rather than looking for compare-select sequences. > >

...VM Developers Mailing List >> Subject: Re: [LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics >> >> … actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]: >> >> minNum(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN. Otherwise, it is either x or y (this means results might differ among implementations). >> >> So I think your proposed semantics are perfectly reasonable. >> >> – Steve >&gt...

On Fri, Sep 12, 2014 at 3:04 PM, Owen Anderson <resistor at mac.com> wrote: > > On Sep 12, 2014, at 2:24 PM, Owen Anderson <resistor at mac.com> wrote: > > > On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > >> More generally, I don’t see a compelling reason for LLVM to add intrinsic >> support for the version you’re

...is against every decision I remember. Saying it out loud in a meeting is one thing, writing them down and implementing and having to bear the maintenance costs is another entirely. That's why the consensus has to happen on the list. >> For a min/max reduction, why not just extend @llvm.minnum and @llvm.maxnum? > > For the same reasons that we don't re-use the other binary operator > instructions like add, sub, mul. The vector versions of those are not > horizontal operations, they instead produce vector results. Sorry, I meant min/max + reduce, just like above. %su...

...ntioning in the notes: LLVM: - the assume intrinsic - scoped noalias metadata - the old JIT being removed - kaleidoscope debug info chapter - TargetMachine/TargetSubtargetInfo API changes - AArch64 FastISel improvements - the new CFL alias analysis - the new vector shuffle lowering - Go bindings - minnum/maxnum intrinsics - statepoint intrinsics Clang: - C++14 support was marked complete - C now defaults to C11 mode - thread-safety analysis was updated - MS ABI compatibility - fpic and -fPIC are now different