On Oct 14, 2008, at 5:41 PM, Chris Lattner wrote:> 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 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__)); > > 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 @code{char} type. clearly, is _m64 is to be treated as char, then, all stores before it are complete and no loads can be moved before it, unless you can't tell that this happened. As for what it allows, it allows many things, including the original snippet that was said to violate strict aliasing. I can't fathom any other reading, what am I missing?
On Tue, Oct 14, 2008 at 11:43 PM, Mike Stump <mrs at apple.com> wrote:> On Oct 14, 2008, at 5:41 PM, Chris Lattner wrote: >> 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 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__)); >> >> 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 @code{char} type. > > clearly, is _m64 is to be treated as char, then, all stores before it > are complete and no loads can be moved before it, unless you can't > tell that this happened. As for what it allows, it allows many > things, including the original snippet that was said to violate strict > aliasing. I can't fathom any other reading, what am I missing?The may_alias you're pointing to was added relatively recently, a bit before gcc 4.2 was released; note that it only affects stuff using the _m64 type as opposed to defining a similar vector type. -Eli
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 > any other type of objects, just like the @code{char} type. > > clearly, is _m64 is to be treated as char, then, all stores before it > are complete and no loads can be moved before it, unless you can't > tell that this happened. As for what it allows, it allows many > things, including the original snippet that was said to violate strict > aliasing. I can't fathom any other reading, what am I missing?Aha, gotcha. I misunderstood the connection. In any case, the important distinction I wanted to raise was that we're talking about how the IR *models a very specific case*, not *eliminating a capability* of the IR. -Chris
Just for reference, my C example was for my own clarification. I dived into LLVM having to write a TargetMachine and I've been keeping busy without having to learn much IR (yet). I was really trying to use C as a pseudo-IR. I get that the idea is allowing IR to directly express the address of part of a vector complicates (prevents?) certain optimizations. However, due to my own ignorance, I don't understand why. My first thought was that a GEP to part of a vector shouldn't really pose any more complications (restrictions?) than a GEP of the vector as a whole. That's what I was trying to get at with my example. Although I could see how this might complicate, say, mem2reg. I would think that if you don't index with the result of a GEP of the whole vector (or pass it to a function, or...), then moving it into a register is a "clean" operation. However, a GEP of part of 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 instead assumed to be able to >> alias >> any other type of objects, just like the @code{char} type. >> >> clearly, is _m64 is to be treated as char, then, all stores before it >> are complete and no loads can be moved before it, unless you can't >> tell that this happened. As for what it allows, it allows many >> things, including the original snippet that was said to violate >> strict >> aliasing. I can't fathom any other reading, what am I missing? > > Aha, gotcha. I misunderstood the connection. > > In any case, the important distinction I wanted to raise was that > we're talking about how the IR *models a very specific case*, not > *eliminating a capability* of the IR. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev