[LLVMdev] Making GEP into vector illegal?

[Dan Gohman]

On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote:

> Hi,
>
> I ran into a case where ScalarReplAggregates can not promote an array
> of vectors into registers, e..g,
>   	%a = alloca [8 x <2 x float>], align 8
>         %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0,
> i32 1, i32 0		; <float*> [#uses=2]
> 	%tmp76 = load float* %arrayidx74597, align 8
>         %arrayidx74598 = getelementptr [8 x <2 x float>]* %a, i32 0,
> i32 1, i32 1		; <float*> [#uses=2]
> 	%tmp77 = load float* %arrayidx74598, align 4
>
> Though we could change the algorithm to look through the vector index,
> it lead to an interesting question about if we should allow a
> getelementptr (GEP) into a vector.
>
> A vector is not like an short array of elements.  It is more of an
> entity in itself.  When dealing with vectors, it seems to me that it
> is  cleaner to think of them as an entity and GEP to the vector and
> then use extract element to access the element of the vector instead
> of using a GEP to get a pointer into a vector and loading it
> directly.  If a client wants to do this, it would seem cleaner to
> force the client to bitcast it to an array and then do a GEP to the
> element.  This would it more similar to what clients have to do to get
> to a pointer to a byte in a word today.  For ScalarReplAggr, we would
> want to promote the vector itself and not to treat it as promoting the
> float elements.
>
> I would like to make it illegal to GEP into a vector as I think it is
> cleaner and more consistent.  Opinions?  Comments?

I agree that disallowing GEP from indexing into vector elements seems
a little cleaner and more consistent. I have used GEPs to index into
vectors once (in code not in the LLVM tree), but I'm pretty sure that
code could be rewritten to avoid needing that.

It's currently illegal to bitcast directly to or from an array type
though, so the workaround for people who need to index into vector
elements with a GEP is to bitcast the GEP's pointer operand.

Dan