Visual Studio 2017：_mm_load_ps 经常编译为 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。如果我知道 struct 分配在一个对齐的地址并且我通过 this* 调用它，那么使用 movaps 是安全的，对吧？

Answer 1

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

为 AVX 或更高版本编译时：

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

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

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

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

新关联：

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

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

---

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

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