search for: maxnum

...gt; bug's still open it probably hasn't actually been implemented. Yes, it's x86_64. That makes sense, but I can't find the needed library, which was what I first tried. I already have -lm in my link command, and nm on my libm doesn't get it. With a link name like "llvm.maxnum.f32", I would expect it to be provided by the llvm distribution. But I find no occurrence in either my installed lib directory nor my build directory, using nm and grep. The closest I can find is a mangled name with only "maxnum" as a substring. In my source directory, it occurs o...

...erson <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, and its...

I have a smallish compilation that contains calls on intrinsics @llvm.maxnum.f32 and @llvm.fabs.f32: %fminmax = call float @llvm.maxnum.f32(float %fabs5, float %fabs) %fabs = call float @llvm.fabs.f32(float %v.6) The latter is reduced to machine code by llc, the former is not, instead coming through as an external function call, which then fails to link. I can'...

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: Follows the...

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>

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

I have numerous objects, each containing continuous data representing the same variable, movement rate, yet each having a different number of rows. e.g. d1<-as.matrix(rnorm(5)) d2<-as.matrix(rnorm(3)) d3<-as.matrix(rnorm(6)) How can I merge these three columns side-by-side in order to create a table regardless of the difference in length? I wish to analyze the output in a spreadsheet

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

...ions in C/Fortran, which can be dynamically loaded into R, and that the extension code can access R functions and data. But that's all still running under R. What about a program that dynamically loads R itself (trivial example follows): #include <stdio.h> #include <R.h> #define MAXNUM = 100; int main(int argc, char **argv) { int n; int i[MAXNUM]; for(n = 1 ; n < argc && n <= MAXNUM ; n++) { i[n-1] = atoi(argv[n]); } printf("mean: %4.2f\n", R_mean(i, n - 1)); exit(0); } % gcc -lR mean.c -o mean % mean 4 5 6 7 mean: 5.5...

...try *fdb; + + rcu_read_lock(); + fdb = __br_fdb_get(br, addr); + if (fdb) + atomic_inc(&fdb->use_count); + rcu_read_unlock(); + return fdb; +} + + void br_fdb_put(struct net_bridge_fdb_entry *ent) { if (atomic_dec_and_test(&ent->use_count)) @@ -229,9 +238,9 @@ memset(buf, 0, maxnum*sizeof(struct __fdb_entry)); - read_lock_bh(&br->hash_lock); + rcu_read_lock(); for (i = 0; i < BR_HASH_SIZE; i++) { - hlist_for_each_entry(f, h, &br->hash[i], hlist) { + hlist_for_each_entry_rcu(f, h, &br->hash[i], hlist) { if (num >= maxnum) goto out; @...

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

...an 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 hardware instruction...

...78 is also fixed as of today. > > So that leaves the problem with fmin/fmax when no fast-math-flags are > specified. We need to update the LangRef with whatever the expected > behavior is for NaN and -0.0. > x86 will probably be poor regardless of whether we choose > "llvm.maxnum" or "llvm.maximum" semantics. > > On Thu, Apr 9, 2020 at 1:28 PM Craig Topper via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > No we still use the shuffle expansion which is why the issue isn't > uni...

...i?id=45378 is also fixed as of today. > > So that leaves the problem with fmin/fmax when no fast-math-flags are > specified. We need to update the LangRef with whatever the expected > behavior is for NaN and -0.0. > x86 will probably be poor regardless of whether we choose "llvm.maxnum" or > "llvm.maximum" semantics. > > On Thu, Apr 9, 2020 at 1:28 PM Craig Topper via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> No we still use the shuffle expansion which is why the issue isn't unique >> to the intrinsic. >> >&g...

...e 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 reductions: >&g...

...order ±0 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...

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

No we still use the shuffle expansion which is why the issue isn't unique to the intrinsic. ~Craig On Thu, Apr 9, 2020 at 10:21 AM Amara Emerson <aemerson at apple.com> wrote: > Has x86 switched to the intrinsics now? > > On Apr 9, 2020, at 10:17 AM, Craig Topper <craig.topper at gmail.com> wrote: > > That recent X86 bug isn't unique to the intrinsic. We

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