简单构造函数的复杂编译器输出

Complex compiler output for simple constructor

我有一个包含两个 64 位整数成员和一个构造函数的结构 X:

struct X
{
    X(uint64_t a, uint64_t b)
    {
        a_ = a; b_ = b;
    }

    uint64_t a_, b_;
};

当我查看编译器输出(64 位 Linux 上的 x86-64 gcc 8.3 和 x86-64 clang 8.0.0)时,没有启用优化,我看到以下代码构造函数。

x86-64 gcc 8.3:

X::X(unsigned long, unsigned long):
    push    rbp
    mov     rbp, rsp
    mov     QWORD PTR [rbp-8], rdi
    mov     QWORD PTR [rbp-16], rsi
    mov     QWORD PTR [rbp-24], rdx
    mov     rax, QWORD PTR [rbp-8]
    mov     QWORD PTR [rax], 0
    mov     rax, QWORD PTR [rbp-8]
    mov     QWORD PTR [rax+8], 0
    mov     rax, QWORD PTR [rbp-8]
    mov     rdx, QWORD PTR [rbp-16]
    mov     QWORD PTR [rax+8], rdx
    mov     rax, QWORD PTR [rbp-8]
    mov     rdx, QWORD PTR [rbp-24]
    mov     QWORD PTR [rax], rdx
    nop
    pop     rbp
    ret

x86-64 铿锵声 8.0.0:

X::X(unsigned long, unsigned long):
    push    rbp
    mov     rbp, rsp
    mov     qword ptr [rbp - 8], rdi
    mov     qword ptr [rbp - 16], rsi
    mov     qword ptr [rbp - 24], rdx
    mov     rdx, qword ptr [rbp - 8]
    mov     qword ptr [rdx], 0
    mov     qword ptr [rdx + 8], 0
    mov     rsi, qword ptr [rbp - 16]
    mov     qword ptr [rdx + 8], rsi
    mov     rsi, qword ptr [rbp - 24]
    mov     qword ptr [rdx], rsi
    pop     rbp
    ret

有谁知道为什么输出如此复杂?我本来希望有两个简单的 "mov" 语句,即使没有启用优化。

未优化的代码总是将所有 C++ 变量(包括函数参数)存储到语句之间的内存位置,so that the values are available for the debugger to read and even modify。 (并且因为它没有花任何时间进行寄存器分配。)这包括在函数的第一个 C++ 语句之前将寄存器参数存储到内存。


这是来自 gcc -masm=intel 的 Intel 语法程序集,因此它使用目标、源代码顺序。 (我们可以根据使用 PTR、方括号和寄存器名称缺少 % 来判断。)

前 3 个存储是根据 x86-64 System V ABI 的调用约定在寄存器 RDI、RSI 和 RDX 中传递的函数参数 (this, a, b)

mov     QWORD PTR [rbp-8], rdi        # this
mov     QWORD PTR [rbp-16], rsi       # a
mov     QWORD PTR [rbp-24], rdx       # b

现在它正在将 this 加载到 rax 并将零写入 a_b_,因为您没有使用正确的构造函数初始化。或者您可能使用此处未显示的一些代码或奇怪的编译器选项将初始化添加为零。

mov     rax, QWORD PTR [rbp-8]
mov     QWORD PTR [rax], 0           # this->a_ = 0
mov     rax, QWORD PTR [rbp-8]
mov     QWORD PTR [rax+8], 0         # this->b_ = 0

然后它再次将 this 加载到 rax 并将 a 加载到 rdx,然后将 this->a_ 写入 rdx 又名 a. b.

同样如此

等等,实际上必须先写入 b_,然后再写入 a_,因为需要结构来匹配声明和内存顺序。所以 [rax+8] 必须是 b_,而不是 a_

mov     rax, QWORD PTR [rbp-8]
mov     rdx, QWORD PTR [rbp-16]        # reload a
mov     QWORD PTR [rax+8], rdx         # this->b_ = a
mov     rax, QWORD PTR [rbp-8]
mov     rdx, QWORD PTR [rbp-24]        # reload b
mov     QWORD PTR [rax], rdx           # this->a_ = b

所以你的 asm 与你问题中的 C++ 源不匹配。

正如其他人评论的那样,编译器没有义务在您不要求时优化您的代码,但很多低效率源于:

  • 编译器在函数入口处将寄存器中传递的参数溢出到堆栈上的保存区域(然后使用堆栈上的副本)
  • Intel 没有内存到内存 MOV 指令的事实

这两个因素结合在一起为您提供了在反汇编中看到的代码(尽管在这里 clang 显然比 gcc 做得更好)。

编译器将这些寄存器溢出到堆栈中以使调试更容易 - 因为它们在堆栈上,所以传递给函数的参数在整个函数中保持可用,这在调试时非常有用。此外,当您意识到它们的实际值应该是什么并希望继续调试会话时,您可以在继续执行之前在断点处为上述参数修补新值等技巧。

我不确定为什么两个编译器在反汇编中分配给它们之前都将 a_b_ 归零。我没看到这个 over at Godbolt

发生了什么,为什么?

如果不打开优化,编译器会将所有变量存储在堆栈上,并且编译器returns将所有值存储在堆栈上堆栈。它这样做的原因是它使调试器更容易跟踪程序中发生的事情:他们可以观察程序的堆栈。

此外,每个函数都必须在函数进入时更新堆栈指针,并在函数退出时重置堆栈指针。这也是为了调试器的好处:调试器总是可以准确地告诉您何时进入函数或退出函数。

代码 -O0:

X::X(unsigned long, unsigned long):
    push    rbp        // Push the frame pointer to the stack
    mov     rbp, rsp   // Copy the frame pointer to the rsb register
    // Create the object (on the stack)
    mov     QWORD PTR [rbp-8], rdi  
    mov     QWORD PTR [rbp-16], rsi
    mov     QWORD PTR [rbp-24], rdx
    mov     rax, QWORD PTR [rbp-8]
    mov     rdx, QWORD PTR [rbp-16]
    mov     QWORD PTR [rax], rdx
    mov     rax, QWORD PTR [rbp-8]
    mov     rdx, QWORD PTR [rbp-24]
    mov     QWORD PTR [rax+8], rdx
    nop     // IDEK why it does this
    // Pop the frame pointer
    pop     rbp
    ret

代码 -O1:

X::X(unsigned long, unsigned long):
    mov     rax, rdi
    mov     rdx, rsi
    ret

这重要吗?

有点。没有优化的代码要慢很多,特别是因为编译器必须做这样的事情。但是几乎没有理由 启用优化。

如何调试优化代码

gcc 和 clang 都有 -Og 选项:这个选项打开所有不会干扰调试的优化。如果代码的调试版本 运行 很慢,请尝试用 -Og 编译它。

代码 -Og:

X::X(unsigned long, unsigned long):
    mov     rax, rdi
    mov     rdx, rsi
    ret

资源

有关 -Og 和其他使代码易于调试的选项的更多信息:https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

有关优化和优化选项的更多信息:https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options