search for: ptr_z

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 th...

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...

...r >> vector types, and their scalar components. */ >> /* APPLE LOCAL 4505813 */ >> typedef long long __m64 __attribute__ ((__vector_size__ (8), >> __may_alias__)); > > This is actually completely different AFAIK, That statement was that: > float4 a; > float* ptr_z = (float*)(&a) + 3; ``violates strict aliasing`` That assertion is wrong. The docs says: @item may_alias Accesses to objects with types with this attribute are not subjected to type-based alias analysis, but are instead assumed to be able to alias any other type of objects, just like the @c...

On Oct 14, 2008, at 11:43 PM, Mike Stump wrote: > That statement was that: > >> float4 a; >> float* ptr_z = (float*)(&a) + 3; > > ``violates strict aliasing`` > > That assertion is wrong. The docs says: > > @item may_alias > Accesses to objects with types with this attribute are not subjected > to > type-based alias analysis, but are instead assumed to be able to alias...

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

...tr_x, "tmp2", false, label_entry); LoadInst* float_tmp5 = new LoadInst(ptr_y, "tmp5", false, label_entry); BinaryOperator* float_tmp6 = BinaryOperator::create(Instruction::Add, float_tmp2, float_tmp5, "tmp6", label_entry); StoreInst* void_20 = new StoreInst(float_tmp6, ptr_z, false, label_entry); GetElementPtrInst* ptr_tmp10 = new GetElementPtrInst(ptr_x, const_int32_13, "tmp10", label_entry); LoadInst* float_tmp11 = new LoadInst(ptr_tmp10, "tmp11", false, label_entry); GetElementPtrInst* ptr_tmp13 = new GetElementPtrInst(ptr_y, const_int32_13, &quo...

...gt; label_entry); > LoadInst* float_tmp5 = new LoadInst(ptr_y, "tmp5", false, > label_entry); > BinaryOperator* float_tmp6 = BinaryOperator::create(Instruction::Add, > float_tmp2, float_tmp5, "tmp6", label_entry); > StoreInst* void_20 = new StoreInst(float_tmp6, ptr_z, false, > label_entry); > GetElementPtrInst* ptr_tmp10 = new GetElementPtrInst(ptr_x, > const_int32_13, > "tmp10", label_entry); > LoadInst* float_tmp11 = new LoadInst(ptr_tmp10, "tmp11", false, > label_entry); > GetElementPtrInst* ptr_tmp13 = new GetEle...

Hi Nicolas (at least, I suspect your signing of your mail with "Anton" was not intentional :-p), > I assume that's the same as the online demo's "Show LLVM C++ API code" > option (http://llvm.org/demo/)? I've tried that with a structure containing > four floating-point components but it also appears to add them individually > using extract/insert. Maybe

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

On Oct 14, 2008, at 4:30 PM, Mike Stump wrote: > 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

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

...gt; label_entry); > LoadInst* float_tmp5 = new LoadInst(ptr_y, "tmp5", false, > label_entry); > BinaryOperator* float_tmp6 = BinaryOperator::create(Instruction::Add, > float_tmp2, float_tmp5, "tmp6", label_entry); > StoreInst* void_20 = new StoreInst(float_tmp6, ptr_z, false, > label_entry); > GetElementPtrInst* ptr_tmp10 = new GetElementPtrInst(ptr_x, > const_int32_13, > "tmp10", label_entry); > LoadInst* float_tmp11 = new LoadInst(ptr_tmp10, "tmp11", false, > label_entry); > GetElementPtrInst* ptr_tmp13 = new GetEle...

...the vector would immediately put you into a more complicated situation. Or something like that... Dan On Oct 15, 2008, at 11:22 AM, Chris Lattner wrote: > On Oct 14, 2008, at 11:43 PM, Mike Stump wrote: >> That statement was that: >> >>> float4 a; >>> float* ptr_z = (float*)(&a) + 3; >> >> ``violates strict aliasing`` >> >> That assertion is wrong. The docs says: >> >> @item may_alias >> Accesses to objects with types with this attribute are not subjected >> to >> type-based alias analysis, but are i...