[LLVMdev] Making GEP into vector illegal?

Daniel M Gessel gessel at apple.com
Tue Oct 14 13:34:41 PDT 2008

In Joe programmer language (i.e. C ;) ), are we basically talking  
about disallowing:

float4 a;
float* ptr_z = &a.z;


Won't programmers just resort to:

float4 a;
float* ptr_z = (float*)(&a) + 3;


On Oct 14, 2008, at 3:55 PM, Mon Ping Wang wrote:

> Hi,
> Something like a sequential type makes sense especially in light of
> what Duncan is point out. I agree with Chris that a vector shouldn't
> be treated as a short array.  Vectors have different alignment rules
> and operations.  It make senses to talk about doing operations on
> vectors like add or speak of having a mask for a vector.  I don't feel
> like that it make sense to talk of arrays in that context.  Also, I
> don't think of looping over a vector in the same sense of an array.
> Also for me, a pointer to an 2nd vector element feels very similar to
> getting a pointer to a 2nd word of an 64 bit integer and less than a
> pointer to the 2nd element in an array.  If we go toward treating the
> array model, theoritically one could use extract or insert for an
> array or we get rid of those operations, and have clients uses GEP to
> modify a vector element.  Either of them seems wrong to me for  
> vectors.
> -- Mon Ping
> On Oct 14, 2008, at 12:08 PM, Chris Lattner wrote:
>> On Oct 14, 2008, at 11:02 AM, Duncan Sands wrote:
>>> Hi Mon Ping,
>>>> I would like to make it illegal to GEP into a vector as I think it
>>>> is
>>>> cleaner and more consistent.  Opinions?  Comments?
>>> now that arrays are first class types, I think vectors should become
>>> a subclass of ArrayType.  This would get rid of a lot of duplicated
>>> code, and also fix a bunch of problems with vectors (eg: that sizes
>>> are wrong; currently we think that a <n x i1> has length n bits, and
>>> that a vector <n x x86_fp80> has length 80*n bits, both of which are
>>> untenable).
>> I'm happy about factoring the code better, but a vectortype isn't an
>> arraytype (isa<ArrayType>(V) should be false).  Maybe a common base
>> class (like sequential type) would be better?
>>> From this point of view you have to allow GEP into a
>>> vector; the conclusion I suppose is that codegen needs to replace
>>> GEP+load or GEP+store with an extract or insert operation.
>> With that logic, there is no difference at all between an array and
>> vector... I disagree very strongly about this.
>> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list