similar to: Vectorizers code ownership

On 9 Nov 2016 06:04, "Chandler Carruth via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > Just my two cents, but if Craig is up for it, I think this would be a pretty great fit. +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161108/9a73b9e1/attachment.html>

It been a while since I worked on the vectorizers and I think that it's time for someone else to be the code owner. During the conference I talked about this with Arnold and a few other people who were involved in the development of the vectorizers. Based on these discussions I recommend Michael Kuperstein. Michael is committed to improving LLVM and has lots of relevant experience. If approved

Hi,  I'd like to continue the discussion on the X86 backend ownership that started here [1].  I think that Craig Topper would be a great code owner. Several people replied to the email with +1s. Quentin had some concerns. Let's continue the discussion. -Nadav [1] - http://lists.llvm.org/pipermail/llvm-dev/2016-November/106931.html. -------------- next part -------------- An HTML

+1 Thanks Nadav for your help over the last few years! Andrea On Mon, Nov 7, 2016 at 9:20 PM, Matthew Simpson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 > > -- Matt > > On Sun, Nov 6, 2016 at 1:00 AM, Nadav Rotem via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> It been a while since I worked on the vectorizers and I think that it's

+1 - especially since I think Craig convinced Intel that LLVM isn't just a hobby project for him. :) On Thu, Nov 10, 2016 at 5:08 AM, Andrea Di Biagio via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Fwiw, I also think that Craig would be a good code owner. So, my +1 goes > to him :-) > > @Nadav, thanks again for all your kind help and contributions to the x86 >

Thanks for the support Nadav, Zvi, Chandler, Renato, and anyone else I missed. Quetin, to maybe address your concerns. My focus lately has been fixing inconsistency in instruction selection behavior between the older AVX instruction encodings and the new AVX512 encodings. I've also been trying to fix cases where concepts haven't been extended to wider vectors yet. For instance, the

Alright, works for me then! Q. > On Nov 10, 2016, at 10:43 AM, Michael Kuperstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +1 > > On Thu, Nov 10, 2016 at 7:15 AM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > +1 - especially since I think Craig convinced Intel that LLVM isn't just a hobby

> On Oct 24, 2014, at 10:57 AM, Adam Nemet <anemet at apple.com> wrote: > > On Oct 24, 2014, at 4:24 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com <mailto:elena.demikhovsky at intel.com>> wrote: > >> Hi, >> >> We would like to add support for masked vector loads and stores by introducing new target-independent intrinsics. The loop

| |Hi Elena, | |Technically speaking, this seems straightforward. | |I wonder, however, how target-independent this is in a practical |sense; will there be an efficient lowering when targeting any other |ISA? I don't want to get into the territory where, because the |vectorizer is supposed to be architecture independent, we need to |add target-independent intrinsics for all

| |How would this work in this case? The result would need to affect the |legality and cost of the memory instruction. From your poster, it looks |like we're talking about loops with constructs like this: | |for (i =0; i < N; i++) { | if (topVal > b[i]) { | *dst = a[i]; | dst++; | } |} | |is this loop vectorizable at all without these constructs? Good

Hi, Recent Intel architectures AVX-512 and AVX2 provide vector gather and/or scatter instructions. Gather/scatter instructions allow read/write access to multiple memory addresses. The addresses are specified using a base address and a vector of indices. We'd like Vectorizers to tap this functionality, and propose to do so by introducing new intrinsics: VectorValue = @llvm.sindex.load

Hi all, AVX-512 ISA introduces new vector instructions VCOMPRESS and VEXPAND in order to allow vectorization of the following loops with two specific types of cross-iteration dependencies: Compress: for (int i=0; i<N; ++i) If (t[i]) *A++ = expr; Expand: for (i=0; i<N; ++i) If (t[i]) X[i] = *A++; else

I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at

Thanks Sanjay for highlighting this, few days back I also faced similar problem while generating masked store in avx1 mode, found its only supported under avx2 else we scalarize it. > 1) I did not switch-on masked_load/store to AVX1, I can do this. Yes Elena, This should be supported for FP type in avx1 mode (for INT type, I doubt X86 has masked_load/store instruction in avx1 mode).

On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote: > > I tried to retrieve anything from DataLayout. It contains pointer > size, but how can I conclude that the GEP index can’t be widened? > I meant that we'd add a new field giving the preferred size for indexing arithmetic.  On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest

Some thoughts: o To determine the VF for a loop with mixed data sizes, choosing the smallest ensures each vector register used is full, choosing the largest will minimize the number of vector registers used. Which one’s better, or some size in between, depends on the target’s costs for the vector operations, availability of registers and possibly control/memory divergence and trip count. “This is

Yes, masked load/store/gather/scatter are completed. - Elena From: zhi chen [mailto:zchenhn at gmail.com] Sent: Thursday, February 25, 2016 01:20 To: Demikhovsky, Elena <elena.demikhovsky at intel.com> Cc: Sanjay Patel <spatel at rotateright.com>; Nema, Ashutosh <Ashutosh.Nema at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] how to

It seems that http://reviews.llvm.org/D15690 only implemented gather/scatter for AVX-512, but not for AVX/AVX2. Is there any plan to enable gather for AVX/2? Thanks. Best, Zhi On Thu, Feb 25, 2016 at 8:28 AM, Sanjay Patel <spatel at rotateright.com> wrote: > I don't think gather has been enabled for AVX2 as of r261875. > Masked load/store were enabled for AVX with: >

Hi Elena, Are the masked_load and gather working now? Best, Zhi On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena < elena.demikhovsky at intel.com> wrote: > Ø Can we legalize the same set of masked load/store operations for AVX1 > as AVX2? > > Yes, of course. > > > > - * Elena* > > > > *From:* Sanjay Patel [mailto:spatel at

I don't think gather has been enabled for AVX2 as of r261875. Masked load/store were enabled for AVX with: http://reviews.llvm.org/D16528 / http://reviews.llvm.org/rL258675 On Wed, Feb 24, 2016 at 11:39 PM, Demikhovsky, Elena < elena.demikhovsky at intel.com> wrote: > Yes, masked load/store/gather/scatter are completed. > > > > - * Elena* > > > >