[LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP

[David A. Greene]

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 = 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.
>> 
>> Ah, I see.  I actually think multiple indices as in multiple vectors
>> of
>> indices to the GEP above would be pretty rare.
>
> Nadav, David, 
>
> I'd like to understand a bit better the final role of these pointer
> vector types in 64bit architectures, where the pointers are often
> bigger than the elements stored/fetch (e.g, 32bits floats/ints).

The pointers are addresses.  On a 64-bit address machine they will be 64
bits.  On a 32-bit address machine they will be 32 bits.

For a situation like PTX that has multiple addresses sizes, we will need
additional LLVM support.  Right now a pointer can only have one size per
target.

> Will 64bits backends be forced to actually operate with 64bit pointer
> vectors all the time? Or will they be able to retain operations on
> base + 32bit offsets as such?

Are you talking about 32-bit pointers?  If so, Nadav has talked about
vector inttoptr and ptrtoint instructions which I think can address the
need you're getting at.  But I'm a little unclear on what you want.

> In particular, an important use case for 3D software rendering is to
> be able to gather <4 x i32> values, from a i32* scalar base pointer in
> a 64bit address space, indexed by <N x i32> offsets. [1] And it is
> important that the intermediate <N x i32*> pointer vectors is actually
> never instanced, as it wouldn't fit in the hardware SIMD registers,
> and therefore would require two gather operations.

By "fit" are you worried about vector length?  If so, legalize would
have to break up the <N x i32*> vector into two or more smaller vectors.

If you are worried about element size (there are only 32-bit elements)
then inttoptr/ptrtoint should handle it, I think.

                              -Dave