similar to: [LLVMdev] Vectors of Pointers and Vector-GEP

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > Hi, > > Following the discussion in last week’s LLVM developers conference I started working on support for vectors-of-pointers. Vectors of pointers are > needed for supporting scatter/gather operations and are the first step in the direction of supporting predicated architectures. In the attached > patch, I

David, Thanks for the support! I sent a detailed email with the overall plan. But just to reiterate, the GEP would look like this: %PV = getelementptr <4 x i32*> %base, <4 x i32> <i32 1, i32 2, i32 3, i32 4> Where the index of the GEP is a vector of indices. I am not against having multiple indices. I just want to start with a basic set of features. Thanks, Nadav

greened at obbligato.org (David A. Greene) writes: > "Rotem, Nadav" <nadav.rotem at intel.com> writes: > >> Following the discussion in last week’s LLVM developers conference I >> started working on support for vectors-of-pointers. Vectors of >> pointers are needed for supporting scatter/gather operations and are >> the first step in the direction of

Duncan, Thanks for the quick review! Here is a short description (design) of where I am going with this patch: 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as

Yes, indeed I can always fallback to intrinsics. But still, I believe that the case I described is in its essence quite common-place, so it should be a first-class citizen in the LLVM IR. AVX2 is the target ISA I'm thinking of too BTW. Let's forget 3D, and imagine something as trivial as a vectorized i32 => float table look up. I'd expect that the IR would look something like:

I agree that a single vector index is sufficient for many cases. Matt Pharr (from the ISPC compiler), showed me an interesting case where there is a single pointer into an array. In this case we need to have two indices, where the first index is zero. Once the basic patch is in, we can start looking at adding support for arrays and multiple indices. Nadav -----Original Message----- From: David

Hi Hal! This is great! Vector-selects are always profitable compared to scalar selects. They are even emulated using a few Xor/And/Or instructions on platforms that don't have a native 'blend' support. Vector-geps on the other hand are only useful in very specific cases. Currently we do not support Load/Store instructions with a pointer-vector operand, so you need to extract each

David, I agree with you, scatter/gather and predication are orthogonal concepts. In theory, you could implement load/store predication using scatter/gather instructions by loading/storing to dedicated 'dead' stack slots. Having said that, I don't know of any architecture which has scatter/gather but does not have predicated instructions. Looking onward, I definitely want to see

Jose, The scenario you described is probably the most important/common case. Supporting GEPs with a scalar base pointer and multiple indices can indeed assist IR-level optimizations in detecting these patterns and replace them with intrinsics. But even without a single scalar base pointers, optimizations can detect that the base pointer is broadcasted from a scalar. Having said that, I am still

----- Original Message ----- > "Rotem, Nadav" <nadav.rotem at intel.com> writes: > > > David, > > > > Thanks for the support! I sent a detailed email with the overall > > plan. But just to reiterate, the GEP would look like this: > > > > %PV = getelementptr <4 x i32*> %base, <4 x i32> <i32 1, i32 2, i32 > > 3, i32

Hi, I just wanted to let you know that I committed the pointer-vector patch. Thanks, Nadav -----Original Message----- From: David A. Greene [mailto:greened at obbligato.org] Sent: Tuesday, December 06, 2011 00:10 To: Jose Fonseca Cc: David A. Greene; Rotem, Nadav; LLVM Developers Mailing List Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP Jose Fonseca <jfonseca

On Tue, 6 Dec 2011 09:19:43 +0200 "Rotem, Nadav" <nadav.rotem at intel.com> wrote: > Hi, > > I just wanted to let you know that I committed the pointer-vector > patch. Nadav, I just committed a change to BBVectorizer to allow it to generate these (and also vector selects) [>= r154735]. If you have cases where you think these should be generated, and they're

Hi Jose, The proposed IR change does not contribute nor hinder the usecase you mentioned. The case of a base + vector-index should be easily addressed by an intrinsic. The pointer-vector proposal comes to support full scatter/gather instructions (such as the AVX2 gather instructions). Nadav -----Original Message----- From: Jose Fonseca [mailto:jfonseca at vmware.com] Sent: Tuesday, November

> This problem can be solved by sinking the broadcast instruction at codegen-prepare time. I considered this option. We currently don’t have target specific optimizations in codegen-prepare time. (Or I’m wrong?) And it will be very X86-directed optimization. Even gather-scatter intrinsics are considered as common for all targets. And the second reason, why I’d prefer to generate a splat-GEP,

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > David, > > Thanks for the support! I sent a detailed email with the overall > plan. But just to reiterate, the GEP would look like this: > > %PV = getelementptr <4 x i32*> %base, <4 x i32> <i32 1, i32 2, i32 3, i32 4> > > Where the index of the GEP is a vector of indices. I am not

Jose Fonseca <jfonseca at vmware.com> writes: > ----- Original Message ----- >> "Rotem, Nadav" <nadav.rotem at intel.com> writes: >> >> > David, >> > >> > Thanks for the support! I sent a detailed email with the overall >> > plan. But just to reiterate, the GEP would look like this: >> > >> > %PV =

Eli, I understand the need to widen unsigned types. However, I ran into a problem with the current GEP/subscript that clang has. AVX2 gather instructions rely on a 64-bit base pointer and a vector of 32-bit indices. Usually, when vectorizing programs, it is possible to detect that the GEP base pointer is uniform and that the index is variant (and needs to be vectorized). This works really nice

Hi Nadav, > I understand the need to widen unsigned types. However, I ran into a problem with the current GEP/subscript that clang has. > > AVX2 gather instructions rely on a 64-bit base pointer and a vector of 32-bit indices. Usually, when vectorizing programs, it is possible to detect that the GEP base pointer is uniform and that the index is variant (and needs to be vectorized). This

Hi, According to the current GEP syntax, vector GEP requires that each index must be a vector with the same number of elements. %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets I propose to lessen this requirement. Let each index be or vector or scalar. All vector indices must have the same number of elements. The scalar value will mean the splat vector value. %A =

----- Original Message ----- > Jose Fonseca <jfonseca at vmware.com> writes: > > > ----- Original Message ----- > >> "Rotem, Nadav" <nadav.rotem at intel.com> writes: > >> > >> > David, > >> > > >> > Thanks for the support! I sent a detailed email with the overall > >> > plan. But just to