c++ - Visual Studio 2017 : _mm_load_ps often compiled to movups

Question

我正在查看为我的代码生成的程序集(使用 Visual Studio 2017)并注意到 _mm_load_ps 经常(总是？)编译为 movups。

我使用 _mm_load_ps 的数据定义如下:

struct alignas(16) Vector {
    float v[4];
}

// often embedded in other structs like this
struct AABB {
    Vector min;
    Vector max;
    bool intersection(/* parameters */) const;
}

现在，当我使用这个构造时，会发生以下情况:

// this code
__mm128 bb_min = _mm_load_ps(min.v);

// generates this
movups  xmm4, XMMWORD PTR [r8]

由于 alignas(16)，我期待 movaps。在这种情况下，我是否需要其他东西来说服编译器使用 movaps？

编辑:我的问题不同于 this question因为我没有遇到任何崩溃。该结构是专门对齐的，我也在使用对齐分配。相反，我很好奇为什么编译器将 _mm_load_ps(对齐内存的内在函数)切换为 movups。如果我知道结构是在一个对齐的地址分配的，并且我通过这个*调用它，那么使用 movaps 是安全的，对吧？

Answer 1

在最新版本的 Visual Studio 和英特尔编译器(最近是 2013 年后？)中，编译器很少再生成对齐的 SIMD 加载/存储。

为 AVX 或更高版本编译时:

• Microsoft 编译器(>VS2013？)不生成对齐加载。但它仍然会生成一致的商店。
• Intel 编译器(> Parallel Studio 2012？)不再这样做了。但您仍会在 ICC 编译的二进制文件中看到它们，这些二进制文件位于它们的手动优化库中，例如 memset()。
• 从 GCC 6.1 开始，当您使用对齐的内部函数时，它仍然会生成对齐的加载/存储。

编译器被允许这样做，因为当代码编写正确时，它不会丢失功能。本地址对齐时，从 Nehalem 开始的所有处理器都不会因未对齐的加载/存储而受到惩罚。

微软在这个问题上的立场是“通过不崩溃来帮助程序员”。不幸的是，我无法再从 Microsoft 找到此声明的原始来源。在我看来，这恰恰相反，因为它隐藏了错位惩罚。从正确性的角度来看，它还隐藏了不正确的代码。

无论如何，无条件地使用未对齐的加载/存储确实可以稍微简化编译器。

新关联:

• 从 Parallel Studio 2018 开始，英特尔编译器根本不再生成对齐的移动 - 即使对于 Nehalem 之前的目标也是如此。
• 从 Visual Studio 2017 开始，Microsoft 编译器也不再生成对齐的移动 - 即使针对 AVX 之前的硬件也是如此。

这两种情况都会导致旧处理器不可避免的性能下降。但似乎 this is intentional因为英特尔和微软都不再关心旧处理器。

---

唯一不受此影响的加载/存储内在函数是非时间加载/存储。没有未对齐的等价物，因此编译器别无选择。

因此，如果您只想测试代码的正确性，您可以在加载/存储内在函数中替换非时态内在函数。但请注意不要让类似这样的东西进入生产代码，因为 NT 加载/存储(尤其是 NT 存储)是一把双刃剑，如果您不知道自己在做什么，它可能会伤到您。