c++ - C/С++。为什么 volatile 上的简单整数加法可以转换为 gcc 和 clang 上的不同 asm 指令？

Question

我写了一个简单的循环:

int volatile value = 0;

void loop(int limit) {
  for (int i = 0; i < limit; ++i) { 
      ++value;
  }
}

我用 gcc 和 clang(-O3 -fno-unroll-loops) 编译了它并得到了不同的输出。它们的不同之处在于 ++value 部分:

clang :

  add dword ptr [rip + value], 1 # ++value
  add edi, -1                    # --limit
  jne .LBB0_1                    # if limit > 0 then continue looping

海湾合作委员会:

  mov eax, DWORD PTR value[rip] # copy value to a register
  add edx, 1                    # ++i
  add eax, 1                    # increment a copy of value
  mov DWORD PTR value[rip], eax # store incremented copy to value, i. e. ++value
  cmp edi, edx                  # compare i < limit
  jne .L3                       # if i < limit then continue looping

每个编译器上的 C 和 C++ 版本都是相同的 ( https://gcc.godbolt.org/z/5x5jGP )所以我的问题是:

1) gcc 做错了什么吗？复制值有什么意义？

2) 我有 benchmarked该代码，出于某种原因，探查器显示，在 gcc 的版本中，73% 的时间浪费在指令 add edx, 1 上，13% 的时间浪费在 mov DWORD PTR value[rip], eax 上。 code> 和 cmp edi、edx 上占 13%。我对这个结果的解释是否错误？为什么其他加法和移动指令只花费不到 1% 的时间？

3) 为什么在如此原始的代码中 gcc/clang 的性能会有所不同？

Answer 1

这都是因为您使用了 volatile ，而 GCC 没有积极优化它

没有 volatile 的，例如对于单个 ++*int_ptr，您将获得一个内存目标添加。 (希望在针对 Intel CPU 进行调优时不是 inc；inc reg is fine but inc mem costs an extra uop vs. add 1. 不幸的是，gcc 和 clang 都犯了这个错误，并使用 inc mem 和 -march=skylake: https://godbolt.org/z/_1Ri20 )

<小时/>

clang 知道它可以将 volatile 读/写访问折叠到内存目标add的加载和存储部分。

GCC 不知道如何对 volatile 进行此优化。在 GCC 中使用 volatile 通常会导致单独的 mov 加载和存储，从而避免了 x86 通过使用 ALU 指令的 CISC 内存操作数来节省代码大小的能力。在加载/存储机器(如任何 RISC)上，您无论如何都需要单独的加载和存储指令，因此这不会成为问题。

TL:DR:围绕 volatile 的不同编译器内部结构，特别是 GCC 错过的优化。

这种错过的优化并不重要，因为很少使用 volatile 。但如果您愿意，请随时在 GCC 的 bugzilla 上报告该问题。

如果没有 volatile ，循环当然会优化掉。但是您可以看到来自 GCC 或 clang 的单个内存目标 add 只执行 ++*p 的函数。

1) Is gcc doing something wrong? What is the point of copying the value?

它只是将其复制到寄存器。我们通常不称其为“复制”，只是将其放入可以对其进行操作的寄存器中。

<小时/>

请注意，gcc 和 clang 在实现循环条件的方式上也有所不同，clang 优化为仅 dec/jnz(实际上是 add -1，但它会使用 dec) > 使用 -march=skylake 或具有高效 dec 的东西，即不是 Silvermont)。

GCC 在循环条件上花费额外的微指令(在 Intel CPU 上，add/jnz 可以宏融合到单个微指令中)。我不知道为什么它会这样天真地编译它。

73% of time is wasted on instruction add edx, 1

性能计数器通常将缓慢结果归咎于等待的指令，而不是实际上缓慢生成结果的指令。

add edx,1 正在等待 value 的重新加载。由于存在 4 到 5 个周期的存储转发延迟，这是循环中的主要瓶颈。

(无论是在内存目标 add 的多个微指令之间，还是在单独的指令之间，本质上没有区别。循环中没有其他内存访问，因此不会出现 store- 的奇怪影响。如果您不尽快尝试，转发延迟会降低: Adding a redundant assignment speeds up code when compiled without optimization或Loop with function call faster than an empty loop )

Why other addition and move instructions take less than 1% of the time?

因为乱序执行将它们隐藏在关键路径的延迟之下。当统计抽样必须从任何给定周期中同时运行的众多指令中选出一个时，它们非常很少成为受到指责的指令。

3) Why can performance differ on gcc/clang in such a primitive code?

我希望这两个循环以相同的速度运行。您所说的性能是指编译器本身在编写既快速又紧凑的代码方面的表现吗？