GCC编译C代码为何用额外寄存器中转参数而非直接写入rbp栈位

你看到的操作不是GCC额外设计的冗余中转逻辑，是平台调用规则和默认编译模式共同作用的结果，核心原因如下：

• 该行为是x86_64 System V ABI的强制要求。所有x86_64架构下的Linux程序都必须遵守这套调用约定：函数的前6个整型、指针类参数，必须按固定顺序通过rdi、rsi、rdx、rcx、r8、r9传递，只有第7个及之后的参数才需要压入栈。示例中test_function只有4个int参数，main作为调用方把1、2、3、4分别写入edi、esi、edx、ecx（对应上述64位寄存器的低32位，适配int的32位长度），完全是按规范执行，不是编译器额外加的中转步骤。
• 寄存器值写入rbp偏移栈位置的操作，是GCC无优化（默认-O0）编译的专属行为。未开优化时，GCC会给所有函数参数、局部变量在当前函数栈帧上分配独立的可寻址内存，函数进入后第一时间把传参寄存器里的值存到对应栈槽。这么做纯粹是为了方便调试：不管单步过程中寄存器怎么被改写，栈上的参数副本始终稳定，调试器可以随时读取、修改参数值，完全匹配C语言的调试模型预期。如果开-O2及以上优化，这些冗余的栈写入会被直接删掉，空的test_function甚至会被整体优化掉，连传参指令都不会保留。
• 调用方根本不可能直接写入被调用函数的栈内存。函数栈帧是函数自身执行时通过栈操作指令建立的，main调用test_function之前，test_function的栈帧还不存在，main既没有权限也没有合法地址去写所谓"rbp对应的栈内存位置"。就算强行打破约定跨栈帧写内存，效率也远低于寄存器传参：寄存器访问延迟不到1个CPU周期，内存访问哪怕命中L1缓存也要3~4个周期，命中主存的话延迟是寄存器的上百倍，寄存器传参本身就是x86_64比32位x86（32位默认约定所有参数压栈）性能更高的核心设计之一。

补充澄清：贴出的汇编代码中，main全程没有做栈写入传参的操作，所有传参动作都是写寄存器；往栈上写参数的代码是test_function自己执行的，属于自身栈帧初始化的一部分，和调用方无关。

内容的提问来源于stack exchange，提问作者whospugisthis