Is Reinterpreting Casts Between Hardware SIMD Vector Pointers (e.g., `__m256`) and Their Corresponding Scalar Types Undefined Behavior in C ?

Is Reinterpret Casting Between Hardware SIMD Vector Pointer and the Corresponding Type an Undefined Behavior?

In ISO C , the definition of __m256 is not provided, hence, we must refer to the implementations that support __m256 to determine their behavior. Intel's intrinsic defines vector-pointers such as __m256 as being authorized to alias any other object, similar to how ISO C allows char to alias anything.

Implications

Based on this definition, it is allowed to dereference a __m256 instead of using an aligned-load intrinsic like _mm256_load_ps(). Notably, for float/double types, using the intrinsics can simplify the process as they handle the casting from float automatically.

Strict Aliasing Rules

Intel's intrinsics API defines that __m256 types are allowed to alias their scalar type, but not vice-versa. This attribute ensures safe loading from arrays of int[], char[], or other types.

May_alias Attribute

GCC implements __m256 with the may_alias attribute, allowing the compiler to prevent certain aliasing behaviors. However, it's crucial to note that this attribute's effect is one-way, meaning that alias concerns still apply when using int32_t* to read a __m256 type.

Element Access of a Vector

Unlike dereferencing a __m256 as a memory address, accessing vector elements using other types (e.g., int32_t) can be problematic. To reliably access or insert elements, it is recommended to use shuffle intrinsics or GNU C vector syntax.

The above is the detailed content of Is Reinterpreting Casts Between Hardware SIMD Vector Pointers (e.g., `__m256`) and Their Corresponding Scalar Types Undefined Behavior in C ?. For more information, please follow other related articles on the PHP Chinese website!