为什么 gcc 12.2 不优化从 main() 调用的 constexpr 函数中的除法到移位

我一直在使用 Godbolt 编译器并输入以下代码：

constexpr int func(int x)
{
    return x > 3 ? x * 2 : (x < -4 ? x - 4 : x / 2);
}

int main(int argc)
{
    return func(argc);
}

代码有点简单。这里重要的部分是最后除以2func(int x)。由于 x 是一个整数，基本上任何编译器都会将其简化为移位以避免除法指令。

x86-64 gcc 12.2 的汇编-O3（对于 Linux，因此 System V ABI）如下所示：

main:
        cmp     edi, 3
        jle     .L2
        lea     eax, [rdi+rdi]
        ret
.L2:
        cmp     edi, -4
        jge     .L4
        lea     eax, [rdi-4]
        ret
.L4:
        mov     eax, edi
        mov     ecx, 2
        cdq
        idiv    ecx
        ret

你可以看到决赛idiv ecx命令不是移位，而是实际除以 2。我还测试了 clang，clang 实际上将其减少为移位。

main:                                   # @main
        mov     eax, edi
        cmp     edi, 4
        jl      .LBB0_2
        add     eax, eax
        ret
.LBB0_2:
        cmp     eax, -5
        jg      .LBB0_4
        add     eax, -4
        ret
.LBB0_4:
        mov     ecx, eax
        shr     cl, 7
        add     cl, al
        sar     cl
        movsx   eax, cl
        ret

这可能是由于内联吗？我很好奇这里发生了什么。

海湾合作委员会对待main特别是：隐式__attribute__((cold))

So main得到的优化较少（或者更注重大小而不是速度），因为它在大多数程序中通常只调用一次。__attribute__((cold))不太一样-Os（优化大小），但这是朝这个方向迈出的一步，有时会得到成本启发来选择一个简单的除法指令。

As GCC 开发者 Marc Glisse 评论, 不要将代码放入名为的函数中main如果您正在对其进行基准测试或查看它如何优化。（除此之外还可以有其他特殊的东西cold，例如MinGW GCC 额外添加了call到 init 函数，以及gcc -m32添加代码以按 16 对齐堆栈。对于您正在查看的代码来说，所有这些都是您不希望看到的噪音。也可以看看如何从 GCC/clang 汇编输出中消除“噪音”？)

另一个问答显示 GCC 推杆main in the .text.startup部分，以及其他假定的“冷”功能。 （这对于 TLB 和分页局部性有好处；希望整个 init 函数页面可以在进程启动后被逐出。这个想法是代码在main可能只运行一次，真正的工作发生在它调用的某个函数内。如果实际工作内联到 main 中，或者对于简单的程序，情况可能并非如此。）

对于所有代码都在其中的玩具程序来说，这是一个糟糕的启发式方法main，但这就是 GCC 所做的。人们经常运行的大多数真实程序aren't玩具，并且在其他一些函数中有足够的代码，但它没有内联到其中main。尽管如果启发式方法能更聪明一点并删除cold如果事实证明整个程序或循环中的所有函数确实优化为main，因为一些实际的程序非常简单。

您可以使用以下方法覆盖启发式GNU C 函数属性.

• __attribute__((hot)) int main(){ ...以您期望的方式优化
  (Godbolt from 索佩尔的评论，添加了属性）。
• __attribute__((cold))在未调用的函数上main产生idiv.
• __attribute__((optimize("O3")))没有帮助。

int main(int x, char **y){ return x/2; } does仍然使用轮班gcc -O2，所以主要是cold并不总是有这种效果（不像-Os).

但也许你的除法已经是有条件的，GCC 猜测基本块甚至不会每次都运行，所以更有理由让它小而不是快。

疯狂的是，海湾合作委员会-Os对于 x86-64（神箭）确实使用idiv对于有符号除法，常数 2，而不仅仅是任意常数（其中 GCC 通常使用乘法逆元即使在-O0）。如果任何代码大小与带有修正舍入到零（而不是 -inf）的算术右移相比，它不会节省太多，并且可以是much速度较慢，特别是对于 Ice Lake 之前的 Intel 上的 64 位整数。与 AArch64 相同，无论哪种方式都是 2 个固定大小的指令，其中sdiv几乎肯定会慢得多。

sdiv确实在 AArch64 上节省了一些代码大小，以获得更高的 2 次幂（Godbolt），但仍然慢得多，这可能不是一个好的权衡-Os. idiv不保存 x86-64 上的指令（如cdq or cqo需要转换为 RDX），尽管代码大小可能只有几个字节。所以可能只适合-Oz它也会使用的地方push 2 / pop rcx将一个小常量放入寄存器中3 个字节的 x86-64 机器代码而不是 5 个.