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
On Tue, Oct 14, 2008 at 1:34 PM, Daniel M Gessel <gessel at apple.com> wrote:> In Joe programmer language (i.e. C ;) ), are we basically talking > about disallowing: > > float4 a; > float* ptr_z = &a.z; > > ?That's my reading as well; the argument for not allowing it is just to make optimization easier. We don't allow addressing individual bits either, and compilers obviously have to work around that for bitfields. AFAIK, both clang and gcc currently don't allow constructs like "&a.z".> Won't programmers just resort to: > > float4 a; > float* ptr_z = (float*)(&a) + 3; > > ?Maybe... although note that with gcc vector intrinsics, this violates strict aliasing. gcc does allow you to use a slightly more elaborate workaround with a union, though. -Eli
On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote:> Maybe... although note that with gcc vector intrinsics, this violates > strict aliasing. gcc does allow you to use a slightly more elaborate > workaround with a union, though.Hum what's your take on this then: /* The Intel API is flexible enough that we must allow aliasing with other vector types, and their scalar components. */ /* APPLE LOCAL 4505813 */ typedef long long __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); :-)
On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote:> On Tue, Oct 14, 2008 at 1:34 PM, Daniel M Gessel <gessel at apple.com> > wrote: >> In Joe programmer language (i.e. C ;) ), are we basically talking >> about disallowing: >> >> float4 a; >> float* ptr_z = &a.z; >> >> ? > > > That's my reading as well; the argument for not allowing it is just to > make optimization easier. We don't allow addressing individual bits > either, and compilers obviously have to work around that for > bitfields. > > AFAIK, both clang and gcc currently don't allow constructs like > "&a.z". >Yes, that is what we are talking about and Eli is right that it is to make optimization easier.>> Won't programmers just resort to: >> >> float4 a; >> float* ptr_z = (float*)(&a) + 3; >> >> ? > > Maybe... although note that with gcc vector intrinsics, this violates > strict aliasing. gcc does allow you to use a slightly more elaborate > workaround with a union, though. >Sure, someone can write that. Of course, they are making assumptions on how the float4 is stored in memory. From the point of view of the IR, that is fine. We are not generating a GEP into a vector type but GEP from a float pointer. Someone may get worse performance though if someone writes code like that. -- Mon Ping
On Oct 14, 2008, at 1:34 PM, Daniel M Gessel wrote:> 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;This discussion is specifically about how to model this stuff in the LLVM IR, not whether a specific language accepts it. As Eli mentions, no current llvm front-end supports that. However, even if there was one that did, we could model this even if the change happens, so nothing is lost. -Chris