[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