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

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

Jose Fonseca <jfonseca at vmware.com> writes:
> 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.
Yep, I saw that.  I think LLVM IR should support it directly.
> 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.
It can, but it would have to go through varying amounts of pain to do
so.  This is such a common operation that the IR should really support
it directly.

                           -Dave

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 at vmware.com> writes:
> 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.
Yep, I saw that.  I think LLVM IR should support it directly.
> 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.
It can, but it would have to go through varying amounts of pain to do
so.  This is such a common operation that the IR should really support
it directly.

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

----- Original Message -----
> Jose Fonseca <jfonseca at vmware.com> writes:
> > 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.
> 
> It can, but it would have to go through varying amounts of pain to do
> so.  This is such a common operation that the IR should really
> support
> it directly.
I entirely agree FWIW.

Jose