[LLVMdev] Making GEP into vector illegal?
Mon Ping Wang
monping at apple.com
Tue Oct 14 12:55:27 PDT 2008
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
>>> 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
> 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.
More information about the llvm-dev