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

Posted 2023-02-14

【中文标题】简单构造函数的复杂编译器输出

【英文标题】：Complex compiler output for simple constructor

【发布时间】：2019-08-15 05:13:41

【问题描述】：

我有一个带有两个 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”语句。

【问题讨论】：

a_ = a; b_ = b; 不是初始化。是任务。试试X(uint64_t a, uint64_t b) : a_(a), b_(b)

如果你禁用优化，你不应该期望优化代码。

@NathanOliver 在这种情况下（因为它们是ints）是相同的。

@Artyer 这不是初始化与构造函数主体。任何一个版本都会生成同样奇怪的 mov：gcc.godbolt.org/z/PsJVwr.

是否有可能您发布的程序集实际上不是来自您发布的源代码？如果我添加诸如uint64_t a_ = 0;

之类的课堂作业，我只会得到归零

【参考方案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++ 源代码不匹配。

【讨论】：

gcc -fverbose-asm 将使用 C++ var 名称为操作数注释 asm，例如godbolt.org/z/3QNU7v 显示此代码由与问题中相同的编译器编译。 （我想知道这是否是 OP 实际复制 asm 的地方，因为 Godbolt 默认检查 Intel-syntax 框。）但正如 Paul Sanders 提到的，gcc8.3 和 clang8.0 不为零 a_ 和 @987654348 @ 在分配参数之前。

哦，很好地发现了 OP 的代码 asm 和 C++ 甚至不匹配。这不仅仅是在a_ = a 之前执行b_ = b（编译器永远不会在-O0 执行此操作），它正在执行b_ = a。或者它具有以相反顺序声明的结构成员。我用实际情况评论了您答案中的代码块。顺便说一句，我很确定 asm 是从 Godbolt 编译器资源管理器中复制的，因为 X::X(unsigned long, unsigned long): 名称、Intel 语法默认值以及 .cfi_* stack-unwind-info 指令和其他元数据内容的过滤。

【参考方案2】：

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

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

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

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

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

【参考方案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

【讨论】：

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

在Why does clang produce inefficient asm with -O0 (for this simple floating point sum)? 中，我更详细地说明了为什么-O0 codegen 如此讨厌：调试器可以在语句之间的断点处停止时修改任何变量，甚至跳转到同一函数内的不同源代码行。这就是为什么没有通过变量进行常量传播的原因。