gcc - 为什么 gcc 不将 _mm256_loadu_pd 解析为单个 vmovupd？

Question

我正在编写一些 AVX 代码，我需要从可能未对齐的内存中加载。我目前正在加载 4 个 double ，因此我将使用内部指令 _mm256_loadu_pd ;我写的代码是:

__m256d d1 = _mm256_loadu_pd(vInOut + i*4);

然后我用选项编译 -O3 -mavx -g随后使用 objdump 获取汇编代码以及带注释的代码和行( objdump -S -M intel -l avx.obj )。当我查看底层汇编代码时，我发现以下内容:

vmovupd xmm0,XMMWORD PTR [rsi+rax*1]
vinsertf128 ymm0,ymm0,XMMWORD PTR [rsi+rax*1+0x10],0x1

我期待看到这个:

vmovupd ymm0,XMMWORD PTR [rsi+rax*1]

并完全使用 256 位寄存器 (ymm0)，而看起来 gcc 已决定填充 128 位部分 (xmm0)，然后使用 vinsertf128 再次加载另一半。

有人能解释一下吗？
在 MSVC VS 2012 中使用单个 vmovupd 编译等效代码。

我在运行 gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0在 Ubuntu 18.04 x86-64 上。

Answer 1

GCC 的默认调优 ( -mtune=generic ) 包括 -mavx256-split-unaligned-load和 -mavx256-split-unaligned-store ，因为在某些情况下，当内存在运行时实际上未对齐时，这会在某些 CPU(例如第一代 Sandybridge 和某些 AMD CPU)上提供较小的加速。

使用 -O3 -mno-avx256-split-unaligned-load -mno-avx256-split-unaligned-store如果你不想要这个，或者更好，使用 -mtune=haswell . 或使用 -march=native为您自己的计算机进行优化。没有“通用 avx2”调整。 ( https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html )。

英特尔 Sandybridge 将 256 位加载作为单个 uop 运行，在加载端口中需要 2 个周期。 (与 AMD 将所有 256 位向量指令解码为 2 个单独的 uops 不同。)Sandybridge 存在未对齐的 256 位加载问题(如果地址在运行时实际上未对齐)。我不知道细节，也没有找到关于减速究竟是什么的具体信息。也许是因为它使用了带 16 字节存储体的存储缓存？但是 IvyBridge 可以更好地处理 256 位负载，并且仍然具有存储缓存。

根据 GCC 邮件列表中关于实现选项 ( https://gcc.gnu.org/ml/gcc-patches/2011-03/msg01847.html ) 的代码的消息，“ 将某些 SPEC CPU 2006 基准测试的速度提高了 6%。”(我认为这是针对 Sandybridge，只有当时存在的 Intel AVX CPU。)

但是，如果内存在运行时实际上是 32 字节对齐的，那么即使在 Sandybridge 和大多数 AMD CPU 上，这也是纯粹的缺点1 .因此，使用此调整选项，您可能会因为未能将对齐保证告知编译器而蒙受损失。如果你的循环大部分时间运行在对齐的内存上，你最好至少用 -mno-avx256-split-unaligned-load 编译那个编译单元。或暗示这一点的调整选项。

在软件中拆分总是会产生成本。让硬件处理它使对齐的情况非常有效(除了 Piledriver1 上的存储)，未对齐的情况可能比某些 CPU 上的软件拆分慢。所以这是一种悲观的方法，如果数据真的很可能在运行时没有对齐，而不是在编译时不能保证总是对齐，那么这是有道理的。例如也许您有一个大部分时间都使用对齐缓冲区调用的函数，但您仍然希望它适用于使用未对齐缓冲区调用的罕见/小情况。在这种情况下，即使在 Sandybridge 上，拆分加载/存储策略也是不合适的。

缓冲区通常是 16 字节对齐但不是 32 字节对齐，因为 malloc在 x86-64 glibc(和 libstdc++ 中的 new)上返回 16 字节对齐的缓冲区(因为 alignof(maxalign_t) == 16 )。对于大缓冲区，指针通常在页面开始后 16 个字节，因此对于大于 16 的对齐总是未对齐。使用 aligned_alloc反而。

请注意 -mavx和 -mavx2根本不要更改调整选项 :gcc -O3 -mavx2仍然适用于所有 CPU，包括那些不能实际运行 AVX2 指令的 CPU。这非常愚蠢，因为如果针对“平均 AVX2 CPU”进行调整，您应该使用单个未对齐的 256 位负载。不幸的是 gcc 没有选择这样做，而且 -mavx2并不意味着 -mno-avx256-split-unaligned-load或任何东西。 见 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80568和 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762对于具有指令集选择影响调整的功能请求 .

这就是为什么你应该使用 -march=native制作本地使用的二进制文件，或者 -march=sandybridge -mtune=haswell制作可以在各种机器上运行的二进制文件，但可能主要在具有 AVX 的较新硬件上运行。 (请注意，即使 Skylake Pentium/Celeron CPU 也没有 AVX 或 BMI2；可能在 256 位执行单元或寄存器文件的上半部分有任何缺陷的 CPU 上，它们禁用 VEX 前缀的解码并将它们作为低端奔腾。)

gcc8.2 的调优选项如下。 ( -march=x 意味着 -mtune=x )。 https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html .

我查了 on the Godbolt compiler explorer通过编译 -O3 -fverbose-asm并查看评论，其中包括所有隐含选项的完整转储。我包括 _mm256_loadu/storeu_ps函数，以及一个可以自动向量化的简单浮点循环，所以我们也可以看看编译器做了什么。

使用 -mprefer-vector-width=256 (gcc8) 或 -mno-prefer-avx128 (gcc7 及更早版本)覆盖调整选项，如 -mtune=bdver3并根据需要获得 256 位自动矢量化，而不仅仅是手动矢量化。

默认/-mtune=generic : 两者 -mavx256-split-unaligned-load和 -store .可以说随着 Intel Haswell 越来越不合适，后来变得越来越普遍，我认为最近 AMD CPU 的缺点仍然很小。尤其是拆分未对齐的负载，AMD 调整选项无法启用这些负载。

-march=sandybridge和 -march=ivybridge : 分开两个。 (我想我已经读过 IvyBridge 改进了对未对齐的 256 位加载或存储的处理，因此它不太适合在运行时可能对齐数据的情况。)

-march=haswell 及更高版本:均未启用拆分选项。

-march=knl : 没有启用拆分选项。 (Silvermont/Atom 没有 AVX)

-mtune=intel : 没有启用拆分选项。即使使用 gcc8，使用 -mtune=intel -mavx 自动矢量化选择达到读/写目标数组的对齐边界，这与 gcc8 仅使用未对齐的常规策略不同。 (同样，另一个总是有成本的软件处理案例，而不是让硬件处理异常(exception)情况。)

-march=bdver1 (推土机):-mavx256-split-unaligned-store ，但不加载。
它还设置了 gcc8 等效的 gcc7 和更早版本 -mprefer-avx128 (自动矢量化将仅使用 128 位 AVX，但内在函数当然仍然可以使用 256 位矢量)。

-march=bdver2 (打桩机), bdver3 (压路机)，bdver4 (挖掘机)。和推土机一样。他们自动矢量化一个 FP a[i] += b[i]使用软件预取和足够的展开循环，每个缓存行只预取一次!

-march=znver1 (禅):-mavx256-split-unaligned-store但不加载，仍然只使用 128 位自动矢量化，但这次没有 SW 预取。

-march=btver2 ( AMD Fam16h, aka Jaguar ):既没有启用拆分选项，也没有像推土机系列那样自动矢量化，只有 128 位矢量 + SW 预取。

-march=eden-x4 (通过带有 AVX2 的 Eden):既没有启用拆分选项，也没有启用 -march选项甚至不启用 -mavx和自动矢量化使用 movlps/movhps 8 字节加载，这真的很愚蠢。至少使用 movsd而不是 movlps打破虚假的依赖。但是如果你启用 -mavx ，它使用 128 位未对齐的加载。这里真的很奇怪/不一致的行为，除非有一些奇怪的前端。

选项(例如，作为 -march=sandybridge 的一部分启用，大概也适用于 Bulldozer 系列(-march=bdver2 是打桩机)。但是，当编译器知道内存已对齐时，这并不能解决问题。

脚注 1:AMD Piledriver 有一个性能错误，导致 256 位存储吞吐量很糟糕:甚至 vmovaps [mem], ymm根据 Agner Fog 的 microarch pdf ( https://agner.org/optimize/)，每 17 到 20 个时钟运行一个对齐的商店。此效果在推土机或压路机/挖掘机中不存在。

Agner Fog 表示，推土机/打桩机上的 256 位 AVX 吞吐量通常(不是专门加载/存储)通常比 128 位 AVX 差，部分原因是它无法以 2-2 uop 模式解码指令。 Steamroller 使 256 位接近收支平衡(如果它不花费额外的洗牌)。但是注册-注册 vmovaps ymm指令仍然只受益于推土机系列上低 128 位的移动消除。

但是闭源软件或二进制发行版通常没有使用 -march=native 构建的奢侈。在每个目标架构上，因此在制作可以在任何支持 AVX 的 CPU 上运行的二进制文件时需要权衡。只要在其他 CPU 上没有灾难性的缺点，在某些 CPU 上使用 256 位代码获得大幅加速通常是值得的。

拆分未对齐的加载/存储是为了避免某些 CPU 出现大问题。在最近的 CPU 上，它需要额外的 uop 吞吐量和额外的 ALU uop。但至少 vinsertf128 ymm, [mem], 1在 Haswell/Skylake 的端口 5 上不需要 shuffle 单元:它可以在任何向量 ALU 端口上运行。 (而且它没有微熔断器，因此需要 2 uop 的前端带宽。)

PS:

大多数代码不是由前沿编译器编译的，因此现在更改“通用”调整需要一段时间才能使用更新的调整编译的代码。 (当然，大多数代码都是用 -O2 或 -O3 编译的，这个选项无论如何只会影响 AVX 代码生成。但不幸的是，许多人使用 -O3 -mavx2 而不是 -O3 -march=native 。所以他们可能会错过 FMA 、BMI1/2、popcnt 以及它们的 CPU 支持的其他东西。