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

Question

我有一个带有两个 64 位整数成员的结构 X 和一个构造函数：

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

    uint64_t a_, b_;
};

当我查看未启用优化的编译器输出（x86-64 gcc 8.3 和 x86-64 clang 8.0.0，在 64 位 Linux 上）时，我看到构造函数的以下代码。

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”语句。

Answer 1

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

---

这是来自gcc -masm=intel 的英特尔语法程序集，因此它使用目标、源顺序。 （我们可以根据使用 PTR、方括号以及寄存器名称中缺少 % 来判断。）

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

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++ 源代码不匹配。

Answer 2

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

• 编译器在进入函数时将寄存器中传递的参数溢出到堆栈上的保留区域（然后使用堆栈上的副本）
• 英特尔没有内存到内存 MOV 指令的事实

这两个因素结合起来可以为您提供您在反汇编中看到的代码（尽管在此，clang 显然比 gcc 做得更好）。

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

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

Answer 3

会发生什么，为什么？

如果不开启优化，编译器会将所有变量存储在堆栈中，编译器会返回堆栈中的所有值。这样做的原因是它使调试器更容易跟踪程序中正在发生的事情：他们可以观察程序的堆栈。

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

代码-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