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?