How to implement “_mm_storeu_epi64” without aliasing problems?

by

SSE intrinsics is one of those niche corner cases where you have to push the rules a bit.

Since these intrinsics are compiler extensions (somewhat standardized by Intel), they are already outside the specification of the C and C++ language standards. So it’s somewhat self-defeating to try to be “standard compliant” while using a feature that clearly is not.

Despite the fact that the SSE intrinsic libraries try to act like normal 3rd party libraries, underneath, they are all specially handled by the compiler.

The Intent:

The SSE intrinsics were likely designed from the beginning to allow aliasing between the vector and scalar types – since a vector really is just an aggregate of the scalar type.

But whoever designed the SSE intrinsics probably wasn’t a language pedant.
(That’s not too surprising. Hard-core low-level performance programmers and language lawyering enthusiasts tend to be very different groups of people who don’t always get along.)

We can see evidence of this in the load/store intrinsics:

  • __m128i _mm_stream_load_si128(__m128i* mem_addr) – A load intrinsic that takes a non-const pointer?
  • void _mm_storeu_pd(double* mem_addr, __m128d a) – What if I want to store to __m128i*?

The strict aliasing problems are a direct result of these poor prototypes.

Starting from AVX512, the intrinsics have all been converted to void* to address this problem:

  • __m512d _mm512_load_pd(void const* mem_addr)
  • void _mm512_store_epi64 (void* mem_addr, __m512i a)

Compiler Specifics:

  • Visual Studio defines each of the SSE/AVX types as a union of the scalar types. This by itself allows strict-aliasing. Furthermore, Visual Studio doesn’t do strict-aliasing so the point is moot:

  • The Intel Compiler has never failed me with all sorts of aliasing. It probably doesn’t do strict-aliasing either – though I’ve never found any reliable source for this.

  • GCC does do strict-aliasing, but from my experience, not across function boundaries. It has never failed me to cast pointers which are passed in (on any type). GCC also declares SSE types as __may_alias__ thereby explicitly allowing it to alias other types.

My Recommendation:

  • For function parameters that are of the wrong pointer type, just cast it.
  • For variables declared and aliased on the stack, use a union. That union will already be aligned so you can read/write to them directly without intrinsics. (But be aware of store-forwarding issues that come with interleaving vector/scalar accesses.)
  • If you need to access a vector both as a whole and by its scalar components, consider using insert/extract intrinsics instead of aliasing.
  • When using GCC, turn on -Wall or -Wstrict-aliasing. It will tell you about strict-aliasing violations.

More Related Contents:

  1. SSE, intrinsics, and alignment
  2. C++ error: ‘_mm_sin_ps’ was not declared in this scope
  3. Get member of __m128 by index?
  4. Visual Studio 2017: _mm_load_ps often compiled to movups
  5. Most efficient way to check if all __m128i components are 0 [using
  6. AVX2 what is the most efficient way to pack left based on a mask?
  7. Is `reinterpret_cast`ing between hardware SIMD vector pointer and the corresponding type an undefined behavior?
  8. How to solve the 32-byte-alignment issue for AVX load/store operations?
  9. print a __m128i variable
  10. Why does optimisation kill this function?
  11. How to efficiently perform double/int64 conversions with SSE/AVX?
  12. Strict aliasing rule and ‘char *’ pointers
  13. SIMD prefix sum on Intel cpu
  14. SSE integer division?
  15. Loading 8 chars from memory into an __m256 variable as packed single precision floats
  16. Using AVX CPU instructions: Poor performance without “/arch:AVX”
  17. How is a vector’s data aligned?
  18. What’s the difference between logical SSE intrinsics?
  19. Intrinsics for CPUID like informations?
  20. Loop unrolling to achieve maximum throughput with Ivy Bridge and Haswell
  21. inlining failed in call to always_inline ‘__m256d _mm256_broadcast_sd(const double*)’
  22. will casting around sockaddr_storage and sockaddr_in break strict aliasing
  23. How to emulate _mm256_loadu_epi32 with gcc or clang?
  24. Do I get a performance penalty when mixing SSE integer/float SIMD instructions
  25. cpu dispatcher for visual studio for AVX and SSE
  26. union for uint32_t and uint8_t[4] undefined behavior? [duplicate]
  27. Emulating shifts on 32 bytes with AVX
  28. reinterpret_cast between char* and std::uint8_t* – safe?
  29. SSE reduction of float vector
  30. VS: unexpected optimization behavior with _BitScanReverse64 intrinsic

Leave a Comment