gcc 和 clang 的 while(i--) 优化：他们为什么不使用 sub / jnc？

Question

有些人在需要不带计数器或带n-1, ..., 0 计数器的循环时编写此类代码：

while (i--) { ... }

一个具体的例子：

volatile int sink;
void countdown_i_used() {
    unsigned i = 1000;
    while (i--) {
         sink = i;  // if i is unused, gcc optimizes it away and uses dec/jnz
    }
}

在 GCC 8.2 (on the Godbolt compiler explorer) 上，它被编译成

# gcc8.2 -O3 -march=haswell
.L2:
    mov     DWORD PTR sink[rip], eax
    dec     eax                      # with tune=generic,  sub eax, 1
    cmp     eax, -1
    jne     .L2

---

在 clang (https://godbolt.org/z/YxYZ95) 上，如果不使用计数器，它会变成

if(i) do {...} while(--i);

但如果使用的话，像 GCC 一样会变成

add esi, -1
cmp esi, -1
jnz lp

---

不过，这似乎是一个更好的主意：

sub esi, 1
jnc lp

这两个编译器为什么不用这种方式？

因为cmp 方式更好？还是因为它们不会以这种方式节省空间而且它们的速度几乎相同？

或者他们只是不考虑这个选项？

---

更新：即使我写代码使用进位方式（这里我使用add/jc但它是一样的）

bool addcy(unsigned& a, unsigned b) {
    unsigned last_a = a;
    a+=b;
    return last_a+b<last_a;
}
volatile unsigned sink;
void f() {

    for (unsigned i=100; addcy(i, -1); ) {
        sink = i;
    }
}

compiler still compile it as checking equality to -1。但是，如果将 100 替换为输入，the JC code remain

Answer 1

是的，这是一个错过的优化。英特尔 Sandybridge 系列可以将 sub/jcc 宏融合到单个 uop 中，因此 sub/jnc 可以节省这些 CPU 上的代码大小、x86 指令和 uops。

在其他 CPU 上（例如 AMD，它只能将 test/cmp 与 jcc 融合），这仍然可以节省代码大小，因此至少稍微好一些。没有什么比这更糟了。

报告https://bugs.llvm.org 和https://gcc.gnu.org/bugzilla/ 上的优化错误是个好主意。