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
On Oct 14, 2008, at 3:08 PM, Chris Lattner wrote:> > On Oct 14, 2008, at 11:02 AM, Duncan Sands wrote:[...]>> 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.Can you elaborate your arguments for that disagreement? (I like the notion that a "vector type" is just a "fixed-length array type" for which I've hinted that the critical operations will be array- wise rather than element-wise.) Daveed
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
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
Hi Chris,> 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?currently anything you can do with an array you can do with a vector. So from this functional viewpoint it would make sense to have a vector be an array with more stuff (i.e. a subclass of ArrayType). However I appreciate that there's a difference: a multi-element vector can be held in a machine register, while that's not the case for an array. But then again, why not place first-class arrays of appropriate size in such machine registers? Also, at the IR level is there any practical advantage to having vectors not be a kind of array - what does disallowing GEP win you? Is this entirely a codegen issue? By the way, deriving from SequentialType doesn't make much sense to me because SequentialType only exists to unify the types on which you can do GEP (at least that's my understanding) - but you want to disallow GEP on vectors!> > 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.There is a difference of course: vectors can do more than arrays. That's why VectorType would derive from ArrayType :) I understand that probably in your head they feel different. I say: change your head! :) Ciao, Duncan.
Hi Duncan, I can see your point that arrays are similar except for the alignment restrictions when representing them in memory. However, the two constructs serves different purpose for me. I don't think of a vector isA array. A vector is a construct that supports a form of parallelism. It is a container that allow people to expression some element wise parallelism in a controlled fashion. It supports parallel operations plus shuffles. Since it is intended to be mostly a parallel construct, it would be nice to avoid writing scalarize code for it when possible (doing an operation on a per element basis instead of the whole vector which GEP seems to imply). An array seems more of a scalar construct where we can discover parallelism when we analyze the pattern of how the array is used. This distinction makes them different for me so I'm not convinced to change my head yet :->. If a vector is a specialized array, do we want to see users use a vector type whenever one has a fix size arrays? It would be convenient for people to do so as you get all the array operations plus you get the vector operations to add two vectors and such. I don't think so as it seems like an abuse of the vector type. It can also be challenging to generate good code for. If the code generator doesn't noticed that it is used mostly scalar, it might break up the vector into some scalar code and then rebuild the vectors back into registers and so forth. -- Mon Ping On Oct 15, 2008, at 10:51 AM, Duncan Sands wrote:> Hi Chris, > >> 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? > > currently anything you can do with an array you can do with a vector. > So from this functional viewpoint it would make sense to have a vector > be an array with more stuff (i.e. a subclass of ArrayType). However I > appreciate that there's a difference: a multi-element vector can be > held > in a machine register, while that's not the case for an array. But > then > again, why not place first-class arrays of appropriate size in such > machine registers? Also, at the IR level is there any practical > advantage > to having vectors not be a kind of array - what does disallowing GEP > win > you? Is this entirely a codegen issue? > > By the way, deriving from SequentialType doesn't make much sense to me > because SequentialType only exists to unify the types on which you can > do GEP (at least that's my understanding) - but you want to disallow > GEP > on vectors! > >>> 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. > > There is a difference of course: vectors can do more than arrays. > That's > why VectorType would derive from ArrayType :) I understand that > probably > in your head they feel different. I say: change your head! :) > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev