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

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

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?

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.

It would be nice to see how this use case would look in the proposed IR, and get
assurance that backends will be able to emit efficient code (i.e., a single
gather instruction) from that IR.

Jose

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-June/040825.html

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 29, 2011 22:25
To: Rotem, Nadav; David A. Greene
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP

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

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?

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.

It would be nice to see how this use case would look in the proposed IR, and get
assurance that backends will be able to emit efficient code (i.e., a single
gather instruction) from that IR.

Jose

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-June/040825.html
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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:

  ; Look Up Table with precomputed values 
  declare float* @lut;

  define <8 x float> @foo(<8 x float> %indices) {
    %pointer = getelementptr float* @lut, <8 x i32> %indices
    %values = load <8 x float*> %pointer
    ret <8 x float> %values;
  }

And the final AVX2 code I'd expect would consist of a single VGATHERDPS,
both on 64bits and 32bits addressing mode:

foo:
  VPCMPEQB   ymm1, ymm1, ymm1                        ; generate all ones
  VGATHERDPS ymm0, DWORD PTR [ymm0 * 4 + lut], ymm1
  RET

Jose

----- Original Message -----
> 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 29, 2011 22:25
> To: Rotem, Nadav; David A. Greene
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and
> Vector-GEP
> 
> ----- 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).
> 
> 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?
> 
> 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.
> 
> It would be nice to see how this use case would look in the proposed
> IR, and get assurance that backends will be able to emit efficient
> code (i.e., a single gather instruction) from that IR.
> 
> Jose
> 
> [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-June/040825.html
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

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

----- 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 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.
I was referring to gathering a vector of sparse 32bit words, all relative from a
base scalar pointer in a 64bit address space, where the offsets are in a 32bit
integer vector.  My other reply gave a more detailed and concrete example.

Anyway, from Nadav's and your other replies on this thread it is now clear
to me that even if the IR doesn't express base scalar pointers w/ vector
indices directly, the backend can always match and emit the most efficient
machine instruction. This addresses my main concern.

Jose