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

David A. Greene greened at obbligato.org
Mon Nov 28 15:57:09 PST 2011


"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 change the LLVM-IR in order to support vectors-of-pointers and added basic support for vector-gep.  In following patches I plan to extend
> the vector-gep support to more indices and add scatter/gather intrinsics.
>
> I started by implementing vector-gep support for a simple case where there is a single index.  The reason for this limitation, as noted by Dan
> Gohman, is that pointers may point to structs, and vectors of indices may point to different members in the struct. I am aware of the fact that
> supporting multiple indices is an important feature and I do intend to add support for multiple indices in the future.

So glad to see this happening!

But I'm unclear about your description.  A vector GEP produces a vector
of pointers, right?  And a scatter/gather operation takes a vector of
pointers as the list of addresses to fetch?

What does the non-unit stride case look like?  I have two ways I think
about a gather/scatter or non-unit stride access.

1. Vector-of-indices

This looks something like:

V1 <- Base + V2

where Base is a base address and V2 is a vector of offsets from the
base.

2. Vector-of-addresses

This looks omsething like:

V1 <- Offset + V2

Where Offset is an offset value applied to each address in V2.

The first form is somewhat more convenient for striding through an array
while the second is somewhat more convenient for doing gather/scatter on
a set of "random" address locations (think operating on a field in
several randomly-allocated structs).

The multiple-index case (if I understand what you mean) is just a
special case of the above, where the values in V2 have been adjusted to
point to the various different fields.

Can you explain with some example what your proposal provides and how it
relates to #1 and #2 above?  I'm just trying to understand the overall
scheme.

Thanks!

                           -Dave




More information about the llvm-dev mailing list