search for: _m64

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

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

...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__)); :-)

...laborate >> 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, this allows things like: ((float*)&myvec4)[2] which is exactly what the proposal wants to continue supporting in the IR. -Chris

...ly with compiler intrinsic which compiles into 1-2 assembly instructions and are much easier to maintain. For example: _mm_sad_epu8(__m128, __m128) will be compiled in PSADBW instruction with compiler-allocated registers. And code like: psadbw mm4,mm5 paddw mm0,mm4 Can be re-written into _m64 mm0, mm4, mm5, mm6, mm7; //of course using meaningful names mm0= _mm_add_epi16(mm0, _mm_sad_pu8(mm4, mm5)); Compiler will replace variables with actual registers, ensuring better allocation and scheduling of them. So, benefits are: 1) Easier to read & understand code which can use same variabl...

...> @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 &g...