缩放索引寻址模式是个好主意吗？

Question

考虑以下代码：

void foo(int* __restrict__ a)
{
    int i; int val = 0;
    for (i = 0; i < 100; i++) {
        val = 2 * i;
        a[i] = val;
    }
}

这个complies（具有最大优化但没有展开或矢量化）到...

GCC 7.2：

foo(int*):
        xor     eax, eax
.L2:
        mov     DWORD PTR [rdi], eax
        add     eax, 2
        add     rdi, 4
        cmp     eax, 200
        jne     .L2
        rep ret

叮当声 5.0：

foo(int*): # @foo(int*)
  xor eax, eax
.LBB0_1: # =>This Inner Loop Header: Depth=1
  mov dword ptr [rdi + 2*rax], eax
  add rax, 2
  cmp rax, 200
  jne .LBB0_1
  ret

GCC 与 clang 方法的优缺点是什么？即一个额外的变量单独递增，而不是通过更复杂的寻址模式相乘？

注意事项：

• 这个问题也与this one 相关，代码大致相同，但使用float 而不是int。

Answer 1

索引寻址（在加载和存储中，lea 仍然不同）有一些权衡，例如

• 在许多 µarch 上，使用索引寻址的指令比不使用的指令延迟稍长。但通常吞吐量是更重要的考虑因素。
• 在 Netburst 上，具有 SIB byte 的存储会生成额外的 µop，因此也可能会消耗吞吐量。无论您是否将 SIB 字节用于索引寻址，SIB 字节都会导致额外的 µop，但索引寻址总是会花费额外的 µop。它不适用于负载。
• 在 Haswell/Broadwell（仍在 Skylake/Kabylake）上，具有索引地址的存储不能使用 port 7 生成地址，而是使用更通用的地址生成端口之一，从而降低了可用于加载的吞吐量。

因此，对于加载，如果它在某处保存添加，则使用索引寻址通常是好的（或不坏的），除非它们是依赖加载链的一部分。对于商店来说，使用索引寻址更危险。在示例代码中，它不应该有很大的不同。保存add 并不真正相关，ALU 指令不会成为瓶颈。端口 2 或 3 中发生的地址生成也无关紧要，因为没有负载。

Answer 2

是的，利用 x86 寻址模式的强大功能来节省 uops，以防索引不分层为更多额外的 uops，而不是执行指针增量所需的成本。

（在许多情况下，展开和使用指针增量是一个胜利，因为英特尔 Sandybridge 系列上的 unlamination，但如果您不展开或仅使用 mov 加载而不是将内存操作数折叠到 ALU 操作中对于微融合，索引寻址模式通常在某些 CPU 上达到收支平衡，而在另一些 CPU 上胜出。）

如果你想在这里做出最佳选择，阅读和理解Micro fusion and addressing modes 是必不可少的。（请注意，IACA 弄错了，并没有模拟 Haswell，后来保留了一些微指令fused，所以你甚至不能通过让它为你做静态分析来检查你的工作。）

---

索引寻址模式通常很便宜。在最坏的情况下，它们会为前端（on Intel SnB-family CPUs in some situations）花费一个额外的微指令，和/或阻止存储地址微指令使用端口 7（仅支持基址 + 位移寻址模式）。有关英特尔在 Haswell 中添加的端口 7 上的 store-AGU 的更多信息，请参阅 Agner Fog's microarch pdf 和 David Kanter's Haswell 文章。
在 Haswell+ 上，如果您需要循环在每个时钟上维持超过 2 个内存操作，请避免使用索引存储。

除了机器码编码中额外字节的代码大小成本之外，它们充其量是免费的。 （拥有索引寄存器需要在编码中使用 SIB（Scale Index Base）字节）。

在英特尔 Sandybridge 系列 CPU 上，与简单的[base + 0-2047] 寻址模式相比，通常唯一的损失是 1 个额外周期的负载使用延迟。

如果要在多条指令中使用索引寻址模式，通常只值得使用额外的指令来避免索引寻址模式。 （例如加载/修改/存储）。

---

如果您已经在使用 2 寄存器寻址模式，则可以免费扩展索引（至少在现代 CPU 上）。对于lea，Agner Fog 的表格将 AMD Ryzen 列为具有 2c 延迟，lea 具有 缩放-index 寻址模式（或 3 分量）的每个时钟吞吐量只有 2 个，否则为 1c 延迟和@ 987654330@ 吞吐量。例如lea rax, [rcx + rdx] 比 lea rax, [rcx + 2*rdx] 快，但不足以值得使用额外的指令。）出于某种原因，Ryzen 也不喜欢 64 位模式下的 32 位目标。但最坏情况下的 LEA 仍然一点也不差。无论如何，大多数情况下与加载的地址模式选择无关，因为大多数 CPU（除了有序 Atom）在 ALU 上运行 LEA，而不是用于实际加载/存储的 AGU。

主要问题是一个寄存器未缩放（因此它可以是机器代码编码中的“基本”寄存器：[base + idx*scale + disp]）或两个寄存器。请注意，由于 Intel 的微融合限制，[disp32 + idx*scale]（例如索引静态数组）是一种索引寻址模式。

---

这两个函数都不是完全最优的（即使不考虑展开或矢量化），但 clang 的看起来非常接近。

clang 唯一可以做得更好的是通过避免带有 add eax, 2 和 cmp eax, 200 的 REX 前缀来节省 2 个字节的代码大小。它将所有操作数提升为 64 位，因为它将它们与指针一起使用，我想证明了 C 循环不需要它们来包装，所以在 asm 中它在任何地方都使用 64 位。这是没有意义的； 32 位操作始终至少与 64 位一样快，并且隐式零扩展是免费的。但这仅花费 2 字节的代码大小，并且除了间接的前端影响之外，不会花费任何性能。

您已经构建了循环，因此编译器需要在寄存器中保留特定值，并且不能将问题完全转换为指针增量 + 与结束指针进行比较（编译器通常在不这样做时会这样做）除了数组索引之外的任何东西都需要循环变量。

您也不能转换为将负索引计数到零（编译器从不这样做，但将循环开销减少到英特尔 CPU 上总共 1 个宏融合 add + 分支 uop（可以融合 add + jcc , 而 AMD 只能融合 test 或 cmp / jcc)。

Clang 做得很好，它注意到它可以使用2*var 作为数组索引（以字节为单位）。这是对 tune=generic 的一个很好的优化。索引存储将在英特尔 Sandybridge 和 Ivybridge 上取消分层，但在 Haswell 及更高版本上保持微融合。 （在其他 CPU，如 Nehalem、Silvermont、Ryzen、Jaguar 或其他 CPU 上，没有劣势。）

gcc 的循环在循环中有 1 个额外的 uop。理论上，它仍然可以在 Core2 / Nehalem 上以每时钟 1 个存储的速度运行，但它正好符合每时钟 4 微指令的限制。 （实际上，Core2 无法在 64 位模式下对 cmp/jcc 进行宏融合，所以它在前端出现了瓶颈）。