简化构造函数却产生了复杂的编译器输出

Question

我有一个结构体 X，其中包含两个 64 位整数成员和一个构造函数：

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

- barcaroller

---

a_ = a; b_ = b; 不是初始化，而是赋值操作。请尝试使用 X(uint64_t a, uint64_t b) : a_(a), b_(b) {} 进行初始化。 - NathanOliver

如果你禁用优化，就不应该期望得到优化后的代码。 - fuz

在这个上下文中，@NathanOliver（因为它们是“int”）是相同的。 - BiagioF

@Artyer 这不是初始化与构造函数体的问题。任何一个版本都会生成相同奇怪的movs: https://gcc.godbolt.org/z/PsJVwr。 - Petr Skocik

你发布的汇编代码是否可能并非与你发布的源代码相对应？只有在添加类内赋值语句（例如uint64_t a_ = 0;）后，我才会得到归零操作。 - Zan Lynx

Answer 1

未优化的代码总是在语句之间将所有C ++变量（包括函数参数）存储到它们的内存位置中，以便调试器可以读取并甚至修改这些值。（因为它没有花费任何时间进行寄存器分配。）这包括在函数的第一个C++语句之前将寄存器参数存储到内存中。

---

这是Intel语法汇编，例如使用“gcc -masm=intel”命令生成的，因此使用目标，源顺序。（我们可以根据PTR、方括号和寄存器名称上缺少“％”符号来判断。）

前三个存储位置（this, a, b）是函数参数，按照x86-64系统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中，并使用rdx(也就是a)写入this->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

因此，你的汇编代码与你问题中的C++源代码不匹配。

- Zan Lynx

---

gcc -fverbose-asm 会使用 C++ 变量名为操作数添加注释，例如 https://godbolt.org/z/3QNU7v 显示了与问题中相同编译器编译的代码。（我想知道这是否是 OP 实际从中复制汇编的地方，因为 Godbolt 默认选中 Intel 语法框。）但正如 Paul Sanders 所提到的，gcc8.3 和 clang8.0 在分配参数之前不会将 a_ 和 b_ 清零。 - Peter Cordes

哦，很好地发现了OP的代码asm和C++甚至不匹配。它不仅在a_ = a之前做了b_ = b（编译器在-O0下永远不会这样做），而且还在做b_ = a。或者它有相反顺序的结构成员声明。我在你的答案中用注释标出了实际发生的情况。顺便说一句，我相当确定asm是从Godbolt编译器探索器复制过来的，因为有解码的X::X(unsigned long, unsigned long):名称，Intel语法默认值以及过滤.cfi_*堆栈展开信息指令和其他元数据内容。 - Peter Cordes

Answer 2

发生了什么，为什么会这样？

如果您不打开优化选项，编译器将所有变量存储在堆栈上，编译器返回所有值也是存储在堆栈上的。它这样做的原因是使调试器更容易跟踪程序的运行情况：它可以观察程序的堆栈。

此外，每个函数进入时都必须更新堆栈指针，在函数退出时重置堆栈指针。这也是为了调试器的好处：调试器始终能够准确地告诉您何时进入或退出函数。

带有-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

- Alecto Irene Perez

---

我认为你在第二段的意思是“更新帧指针”(-fno-omit-frame-pointer)。调试器根据RIP而不是RSP或RBP知道函数何时进入/退出。这对于回溯/堆栈展开非常有用，但是如果没有.eh_frame部分，GDB只会在回溯时退回到帧指针。 - Peter Cordes

在为什么clang使用-O0（对于这个简单的浮点求和）生成效率低下的asm？中，我更详细地解释了为什么-O0代码生成如此恶劣：这是因为调试器可以在语句之间停止断点时修改任何变量，甚至可以跳转到同一函数内的不同源行。这就是为什么没有通过变量进行常量传播的原因，例如。 - Peter Cordes

Answer 3

正如其他评论所说，当您没有要求编译器进行优化时，编译器没有义务优化您的代码，但是许多低效性源于以下因素：

- 编译器将传递给函数的寄存器参数溢出到栈上的保持区域（然后在栈上使用这些副本） - 英特尔没有内存到内存的MOV指令

这两个因素结合起来产生了您在反汇编中看到的代码（尽管clang在这方面显然比gcc做得更好）。

编译器将这些寄存器泄漏到堆栈上以使调试更容易 - 因为它们在堆栈上，所以传递到函数中的参数在整个函数期间仍然可用，这在调试时非常有帮助。此外，您可以在断点处补丁修补前述参数的新值，然后继续执行，当您意识到其实际值并想要继续调试会话时，这可能非常有用。

我不确定为什么两个编译器都会在反汇编中将a_和b_清零后再对它们进行分配。我在Godbolt上没有看到这种情况。

- Paul Sanders