禁用优化的 c alloca 函数的奇怪汇编代码 - gcc 使用常量 16 的 DIV 和 IMUL，并移位？

问题描述

我在 c 中有这个简单的代码

#include <stdio.h>
#include <alloca.h>

int main()
{
    char* buffer = (char*)alloca(600);
    snprintf(buffer,600,"Hello %d %d %d\n",1,2,3);

    return 0;
}

我希望为 alloca 函数生成的汇编代码只会递减堆栈指针（一个子指令），并且可能会做一些对齐（一个和指令），但是生成的汇编代码非常复杂，甚至比你低效' d 期待。

这是objdump -d main.o的输出，在gcc -c的输出上（没有优化，所以默认-O0）

    0000000000400596 <main>:
  400596:   55                      push   %rbp
  400597:   48 89 e5                mov    %rsp,%rbp
  40059a:   48 83 ec 10             sub    $0x10,%rsp
  40059e:   b8 10 00 00 00          mov    $0x10,%eax
  4005a3:   48 83 e8 01             sub    $0x1,%rax
  4005a7:   48 05 60 02 00 00       add    $0x260,%rax
  4005ad:   b9 10 00 00 00          mov    $0x10,%ecx
  4005b2:   ba 00 00 00 00          mov    $0x0,%edx
  4005b7:   48 f7 f1                div    %rcx
  4005ba:   48 6b c0 10             imul   $0x10,%rax,%rax
  4005be:   48 29 c4                sub    %rax,%rsp
  4005c1:   48 89 e0                mov    %rsp,%rax
  4005c4:   48 83 c0 0f             add    $0xf,%rax
  4005c8:   48 c1 e8 04             shr    $0x4,%rax
  4005cc:   48 c1 e0 04             shl    $0x4,%rax
  4005d0:   48 89 45 f8             mov    %rax,-0x8(%rbp)
  4005d4:   48 8b 45 f8             mov    -0x8(%rbp),%rax
  4005d8:   41 b9 03 00 00 00       mov    $0x3,%r9d
  4005de:   41 b8 02 00 00 00       mov    $0x2,%r8d
  4005e4:   b9 01 00 00 00          mov    $0x1,%ecx
  4005e9:   ba a8 06 40 00          mov    $0x4006a8,%edx
  4005ee:   be 58 02 00 00          mov    $0x258,%esi
  4005f3:   48 89 c7                mov    %rax,%rdi
  4005f6:   b8 00 00 00 00          mov    $0x0,%eax
  4005fb:   e8 a0 fe ff ff          callq  4004a0 <snprintf@plt>
  400600:   b8 00 00 00 00          mov    $0x0,%eax
  400605:   c9                      leaveq 
  400606:   c3                      retq   
  400607:   66 0f 1f 84 00 00 00    nopw   0x0(%rax,1)
  40060e:   00 00

知道生成的汇编代码的目的是什么吗？我使用的是 gcc 8.3.1。

解决方法

当然有通常的调试模式/反优化行为，将每个 C 语句编译到一个单独的块，实际上在内存中具有非 register 变量。 (Why does clang produce inefficient asm with -O0 (for this simple floating point sum)?)。

但是是的，这超出了“未优化”的范围。没有理智的人会期望 GCC 的预制指令序列（或 GIMPLE 或 RTL 逻辑，无论它扩展到什么阶段）使 alloca 逻辑通过编译时常量涉及 div 2 的幂，而不是移位或只是一个 AND。如果您自己用 C 源代码编写 x /= 16;，即使使用 div，也不会编译为 gcc -O0。

通常 GCC 会尽可能多地在编译时评估常量表达式，例如 x = 5 * 6 不会在运行时使用 imul。但是它扩展其 alloca 逻辑的点必须在那点之后，可能很晚（在大多数其他传递之后）来解释所有那些错过的优化。因此，它不会从对 C 源代码逻辑进行操作的相同传递中受益。

它在做两件事：

将分配大小向上舍入（将其放入寄存器后的常量 600）为 16 的倍数，执行以下操作：{ {1}}。一个健全的编译器至少会使用右移/左移，如果不是将其优化为 ((16ULL - 1) + x) / 16 * 16。但不幸的是 GCC 使用了 (x+15) & -16 和 div by 16，即使它是 2 的常数次幂。
将分配空间的最终地址四舍五入为 16 的倍数（即使它已经是因为 RSP 开始 16 字节对齐并且分配大小被四舍五入。）它确实这与 imul 比 div/imul 效率高得多（特别是对于 Ice Lake 之前 Intel 上的 64 位操作数大小），但仍然不如 ((p+15) >> 4) << 4 效率。当然，做已经毫无意义的工作很愚蠢。

当然，它必须将指针存储到 and $-16,%rax 中。

在下一条语句的 asm 块中，将其重新加载为 char* buffer 的 arg（效率低下，而不是直接进入 RDI，通常用于 sprintf），同时设置寄存器参数。

所以这很糟糕，但是在大多数转换（“优化”）传递已经运行之后，gcc -O0 的固定逻辑的后期扩展非常有说服力地解释了。注意alloca doesn't literally mean "no optimization"，它的意思就是“编译速度快，调试一致”。