[LLVMdev] Making GEP into vector illegal?
clattner at apple.com
Tue Oct 14 10:24:31 PDT 2008
On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote:
> 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 completely agree with you. Our current approach is similar to
allowing GEP to index into the 3rd byte of an i32 for example.
More information about the llvm-dev