gcc - 比例索引寻址模式是一个好主意吗？

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 vs clang方法的优缺点是什么？也就是说，一个额外的变量单独增加，而不是通过更复杂的寻址模式相乘？

笔记：


这个问题也与具有相同代码但 float而不是 int的 this one有关。

Answer 1

是的，如果索引不会分层成更多的uops，而不是增加指针增量所需的开销，则可以利用x86寻址模式的功能来节省uops。

（在许多情况下，由于在Intel Sandybridge系列上进行分层，因此展开和使用指针增量是一个胜利，但是如果您不展开或仅使用mov加载而不是将内存操作数折叠到用于ALU运算符的ALU操作中，融合，那么索引寻址模式在某些CPU上通常会收支平衡，而在另一些CPU上则是双赢。）

如果您想在此处做出最佳选择，则必须阅读和理解Micro fusion and addressing modes。 （并且请注意，IACA会弄错它，并且不会模拟Haswell，以后又会微微融合一些uops，因此您甚至不能只是通过为您做静态分析来检查工作。）



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

充其量是免费的，除了机器代码编码中额外字节的代码大小成本之外。 （具有索引寄存器需要编码中的SIB（比例索引基础）字节）。

通常，唯一的惩罚是在Intel Sandybridge系列CPU上，负载使用延迟比简单的[base + 0-2047]寻址模式多了1个周期。

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



如果您已经在使用2寄存器寻址模式，则缩放索引是免费的（至少在现代CPU上如此）。对于lea，Agner Fog的表将AMD Ryzen列出为具有缩放索引寻址模式（或3分量）的lea具有2c延迟，每个时钟吞吐量只有2，否则为1c延迟和0.25c吞吐量。例如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个字节的代码大小，并且除了由此产生的间接前端效果外，不花费任何性能。

您已经构建了循环，因此编译器需要在寄存器中保留特定的值，并且不能将问题完全转换为仅指针增加+与结束指针进行比较（编译器通常在不需要循环时执行此操作）变量，用于除数组索引之外的所有内容）。

您也不能转换为将负索引计数到零（编译器从未这样做，但是将循环开销减少到Intel CPU上总共1个宏融合的add + branch uop（可以融合add + jcc，而AMD只能进行保险丝测试或cmp / jcc）。

Clang做得很好，注意到它可以使用2*var作为数组索引（以字节为单位）。对于tune = generic，这是一个很好的优化。被索引的商店将在Intel Sandybridge和Ivybridge上取消分层，但在Haswell和以后的版本上将保持微融合。 （在Nehalem，Silvermont，Ryzen，Jaguar等其他CPU上，也没有缺点。）

gcc的循环中有1个额外的uop。从理论上讲，它仍可以在Core2 / Nehalem上每个时钟运行1个存储，但是正好与每个时钟限制为4 uops。 （实际上，Core2无法在64位模式下对cmp / jcc进行宏熔接，因此它在前端出现了瓶颈）。