开发者

Aliasing of NEON vector data types

开发者 https://www.devze.com 2023-03-30 19:32 出处:网络
Does NEON support aliasing of the vector data types with their scalar components? E.g.(开发者_如何转开发Intel SSE)

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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号