时间戳

首页 > 解决方案 > 为什么 gcc 不将 _mm256_loadu_pd 解析为单个 vmovupd？

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

问题描述

我正在编写一些AVX代码，我需要从可能未对齐的内存中加载。我目前正在加载 4双打，因此我会使用内在指令_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上运行。

标签： gccassemblyvectorizationsimdavx

解决方案

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优化您自己的计算机。没有“generic-avx2”调整。（https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html）。

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

根据关于实现该选项的代码的 GCC 邮件列表消息 ( https://gcc.gnu.org/ml/gcc-patches/2011-03/msg01847.html )，“它通过以下方式加速了一些 SPEC CPU 2006 基准测试高达 6%。 ”（我认为这是针对当时唯一存在的英特尔 AVX CPU 的 Sandybridge。）

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

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

缓冲区通常是 16 字节对齐但不是 32 字节对齐的，因为malloc在 x86-64 上 glibc（以及new在 libstdc++ 中）返回 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。

我通过编译并查看包含所有隐含选项的完整转储的注释来检查Godbolt 编译器资源管理器。-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 仅使用未对齐的正常策略不同。（同样，另一种软件处理总是有成本而不是让硬件处理例外情况。）
  • -march=bdver1（推土机）：，-mavx256-split-unaligned-store但不加载。它还设置了 gcc8 等效的 gcc7 和更早版本-mprefer-avx128（自动矢量化将仅使用 128 位 AVX，但当然内在函数仍然可以使用 256 位矢量）。
  • -march=bdver2（打桩机），bdver3（压路机），bdver4（挖掘机）。和推土机一样。a[i] += b[i]他们使用软件预取和足够的展开来自动矢量化 FP循环，以便每个高速缓存行仅预取一次！
  • -march=znver1(Zen)：-mavx256-split-unaligned-store但不加载，仍然只使用 128 位进行自动矢量化，但这次没有 SW 预取。
  • -march=btver2（AMD Fam16h，又名 Jaguar）：既没有启用拆分选项，也没有启用像 Bulldozer 系列一样的自动矢量化，只有 128 位矢量 + SW 预取。

  • -march=eden-x4（通过带有 AVX2 的 Eden）：既没有启用拆分选项，-march也没有启用该选项-mavx，并且自动矢量化使用movlps/ movhps8 字节加载，这真的很愚蠢。至少使用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 说 Bulldozer/Piledriver 上的 256 位 AVX 吞吐量（不是专门加载/存储）通常比 128 位 AVX 差，部分原因是它无法以 2-2 uop 模式解码指令。Steamroller 使 256 位接近收支平衡（如果它不花费额外的洗牌）。但是寄存器-寄存器vmovaps ymm指令仍然只能从 Bulldozer 系列的低 128 位的 mov 消除中受益。

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

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

PS：

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

推荐阅读