Does NEON support aliasing of the vector data types with their scalar components?
E.g.(开发者_如何转开发Intel SSE)
typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__));
The above will allow me to do:
__m128i* somePtr;
somePtr++;//advance to the next block
Aliasing a la Intel it will allow to advance my pointer to the next block I want to process without managing extra counts and indexes.
The __may_alias__
attribute on __m128i
should be viewed as a work-around which makes it possible to write strict-aliasing-correct code even though Intel completely screwed up the signatures of some of the SEE load/store intrinsics. (The 8-byte loading _mm_loadl_epi64(const __m128i*)
is the most hilarious example, but there are others). ARM got their intrinsics right, so __may_alias__
isn't needed.
Just use pointers to the element type, and use explicit loads and stores. In my experience that leads to better code being generated, and is probably also more portable. (Does the ARM C language spec even allow pointers to NEON types? I wouldn't be surprised if they didn't).
NEON intrinsics implementation does NOT support aliasing of the vector data types with their scalar components.
GCC supports a bunch of intrinsics when you specify -mfpu_neon. One of the ones you'd be interested in, I'm guessing, is int32x4_t. More info about all the types available can be found on the ARM site.
精彩评论