为什么SSE有128位加载函数？
Why are there 128bit load functions for SSE?
我正在研究其他人的代码，目前正试图找出 _mm_load_si128 存在的原因。
基本上，我尝试替换
_ra = _mm_load_si128(reinterpret_cast<__m128i*>(&cd->data[idx]));
和
_ra = *reinterpret_cast<__m128i*>(&cd->data[idx]);
它的工作原理和性能完全一样。
我认为加载函数只是为了方便而存在于较小的类型中，这样人们就不必手动将它们打包到连续内存中，但是对于已经按正确顺序排列的数据，何必呢？
_mm_load_si128还有其他功能吗？或者它本质上只是一种迂回的赋值方式？
SSE中有显式和隐式加载。
_mm_load_si128(reinterpret_cast<__m128i*>(&cd->data[idx])); 是显式加载*reinterpret_cast<__m128i*>(&cd->data[idx]);是隐式加载
通过显式加载，您可以显式指示编译器将数据加载到 XMM 寄存器中 - 这是 "official" Intel 的实现方式。您还可以通过使用 _mm_load_si128 或 _mm_loadu_si128.
来控制负载是对齐负载还是未对齐负载
虽然作为扩展，大多数编译器也能够在您执行 type-punning 时自动生成 XMM 加载，但是这样您无法控制加载是对齐的还是未对齐的。在这种情况下，由于在现代 CPU 上，当数据对齐时使用未对齐加载不会造成性能损失，因此编译器倾向于普遍使用未对齐加载。
另一个更重要的方面是隐式加载违反了 strict aliasing 规则，这可能导致 未定义的行为 。尽管值得一提的是——作为扩展的一部分——支持英特尔内在函数的编译器并不倾向于对 XMM 占位符类型（如 __m128、__m128d、__m128i 强制执行严格的别名规则。
尽管如此，我认为显式加载更干净、更可靠。
为什么编译器不倾向于对 SSE 占位符类型执行严格的别名规则？
第一个原因在于 SSE 内在函数的设计：在某些明显的情况下，您必须使用类型双关，因为没有其他方法可以使用某些内在的。 Mysticial's answer总结的很完美
正如 Cody Gray 在评论中指出的那样，值得一提的是，从历史上看，MMX 内在函数（现在大部分已被 SSE2 取代）甚至没有提供显式加载或存储——您必须使用类型双关。
第二个原因（与第一个有点关系）在于这些类型的类型定义。
GCC 的 typedef 用于 <xmmintrin.h > 和 <emmintrin.h> 中的 SSE/SSE2 占位符类型：
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__));
typedef double __m128d __attribute__ ((__vector_size__ (16), __may_alias__));
这里的关键是 __may_alias__ 属性，即使在使用 -fstrict-aliasing 标志启用严格别名的情况下，它也可以对这些类型进行类型双关。
现在，由于 clang and ICC are compatible with GCC, they should follow the same convention. So currently, in these 3 compilers implicit loads/stores are somewhat guaranteed to work even with -fstrict-aliasing flag. Finally, MSVC 根本不支持严格的别名，所以它甚至不是问题。
不过，这并不意味着您应该更喜欢隐式的 loads/stores 而不是显式的。
我正在研究其他人的代码，目前正试图找出 _mm_load_si128 存在的原因。
基本上，我尝试替换
_ra = _mm_load_si128(reinterpret_cast<__m128i*>(&cd->data[idx]));
和
_ra = *reinterpret_cast<__m128i*>(&cd->data[idx]);
它的工作原理和性能完全一样。
我认为加载函数只是为了方便而存在于较小的类型中，这样人们就不必手动将它们打包到连续内存中，但是对于已经按正确顺序排列的数据，何必呢？
_mm_load_si128还有其他功能吗？或者它本质上只是一种迂回的赋值方式？
SSE中有显式和隐式加载。
_mm_load_si128(reinterpret_cast<__m128i*>(&cd->data[idx]));是显式加载*reinterpret_cast<__m128i*>(&cd->data[idx]);是隐式加载
通过显式加载，您可以显式指示编译器将数据加载到 XMM 寄存器中 - 这是 "official" Intel 的实现方式。您还可以通过使用 _mm_load_si128 或 _mm_loadu_si128.
虽然作为扩展，大多数编译器也能够在您执行 type-punning 时自动生成 XMM 加载，但是这样您无法控制加载是对齐的还是未对齐的。在这种情况下，由于在现代 CPU 上，当数据对齐时使用未对齐加载不会造成性能损失，因此编译器倾向于普遍使用未对齐加载。
另一个更重要的方面是隐式加载违反了 strict aliasing 规则，这可能导致 未定义的行为 。尽管值得一提的是——作为扩展的一部分——支持英特尔内在函数的编译器并不倾向于对 XMM 占位符类型（如 __m128、__m128d、__m128i 强制执行严格的别名规则。
尽管如此，我认为显式加载更干净、更可靠。
为什么编译器不倾向于对 SSE 占位符类型执行严格的别名规则？
第一个原因在于 SSE 内在函数的设计：在某些明显的情况下，您必须使用类型双关，因为没有其他方法可以使用某些内在的。 Mysticial's answer总结的很完美
正如 Cody Gray 在评论中指出的那样，值得一提的是，从历史上看，MMX 内在函数（现在大部分已被 SSE2 取代）甚至没有提供显式加载或存储——您必须使用类型双关。
第二个原因（与第一个有点关系）在于这些类型的类型定义。
GCC 的 typedef 用于 <xmmintrin.h > 和 <emmintrin.h> 中的 SSE/SSE2 占位符类型：
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__));
typedef double __m128d __attribute__ ((__vector_size__ (16), __may_alias__));
这里的关键是 __may_alias__ 属性，即使在使用 -fstrict-aliasing 标志启用严格别名的情况下，它也可以对这些类型进行类型双关。
现在，由于 clang and ICC are compatible with GCC, they should follow the same convention. So currently, in these 3 compilers implicit loads/stores are somewhat guaranteed to work even with -fstrict-aliasing flag. Finally, MSVC 根本不支持严格的别名，所以它甚至不是问题。
不过，这并不意味着您应该更喜欢隐式的 loads/stores 而不是显式的。