Noob compiler question. type-punning (via cast) a primitive array (say 64-bit integers) to a SIMD array is technically illegal (strict aliasing) but it's also (seemingly) ubiquitous. Do any of the main compilers (clang/gcc/vc) have a stance on this?
=> More informations about this toot | More toots from mbr@mastodon.gamedev.place
@mbr if it's heap allocated or was once backed by char, i think it's often safe in theory, not just in practice. For auto or global vars, I stick everything in an union. That's explicitly blessed by clang and gcc.
Or inline asm ;)
=> More informations about this toot | More toots from pkhuong@discuss.systems
@pkhuong @mbr in general I believe the simd types don't participate normally with TBAA, but I'm not sure if that's explicitly stated or just a defacto standard.
=> More informations about this toot | More toots from dotstdy@mastodon.social
@dotstdy @pkhuong @mbr both responses above are wrong :)
vector type introduced via attribute((vector_size)) are compatible with the base type (otherwise autovectorization would not be able to use them)
immintrin.h additionally sticks attribute((may_alias)) on __m128-like types, but not __v4si etc.
=> More informations about this toot | More toots from amonakov@mastodon.gamedev.place
@amonakov @pkhuong @mbr yeah the may_alias is what I mean, in the case of the sse intrinsics that means that type punning always works directly (modulo alignment), and this is load-bearing in a large amount of intrinsics code.
=> More informations about this toot | More toots from dotstdy@mastodon.social
@mbr direct access through the casted pointer, or shoving it into a load/store intrinsic?
A compiler that breaks the load/store intrinsics is straight up trolling.
Direct access.. who knows. Not very interesting IMO since it has another big problem: you cannot portably mark direct access as unaligned.
=> More informations about this toot | More toots from harold@mastodon.gamedev.place
@harold @mbr you can make a typedef of a vector type with reduced alignment: https://godbolt.org/z/9fh5Wqh6h
=> More informations about this toot | More toots from amonakov@mastodon.gamedev.place
@amonakov @mbr yes but not portably
=> More informations about this toot | More toots from harold@mastodon.gamedev.place
@harold @mbr I'm not sure what you're implying? We do not have portable vector types in the first place. If this is about immintrin.h intrinsics on MSVC, from what I see you cannot even write vec1 + vec2, and the point of using C-style access when you need to write out all computations via intrinsics escapes me.
=> More informations about this toot | More toots from amonakov@mastodon.gamedev.place
@amonakov @mbr Isn't the thing we're talking about here, writing *(__m128i*)&something
(direct access) or _mm_load(u)_si128((__m128i*)&something)
?
Sure, doing it the first way isn't particularly of any use, since you could just do it the second way. But that first is somewhat used in practice too. And at least it can be talked about in a hypothetical sense
=> More informations about this toot | More toots from harold@mastodon.gamedev.place
@harold @mbr ah, fair — thanks
=> More informations about this toot | More toots from amonakov@mastodon.gamedev.place
@mbr this example may interest you: https://mastodon.gamedev.place/@amonakov/112438736156730914
=> More informations about this toot | More toots from amonakov@mastodon.gamedev.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini