为什么用-Os编译会使这个函数变大？

Question

考虑这个函数：

long foo(long x) {
    return 5*x + 6;
}

当我用带有< code>-O3(或< code>-O2或< code>-O1)的x86-64 gcc 8.2编译它时，它会编译成这样:

foo:
  leaq 6(%rdi,%rdi,4), %rax  # 5 bytes: 48 8d 44 bf 06
  ret                        # 1 byte:  c3

当我使用-Os时，它编译成这样：

foo:
  leaq (%rdi,%rdi,4), %rax   # 4 bytes: 48 8d 04 bf
  addq $6, %rax              # 4 bytes: 48 83 c0 06
  ret                        # 1 byte:  c3

后者长3个字节。-Os不是应该产生尽可能小的代码吗，即使更大的代码会更有效率？为什么这里似乎发生了相反的情况？

戈德波特:https://godbolt.org/z/jzNquk

Answer 1

与使用＜code>-O1＜/code>、＜code>-O2＜/code>和＜code>-O3＜/code>选项（“优化速度”）生成的代码相比，＜code>-Os＜/code>（“优化大小”）预计会生成更紧凑的代码，但正如@Robert Harvey所评论的，确实没有这样的保证。

优化编译是一个非常复杂和微妙的过程。它由几十个不同的优化阶段组成，这些阶段通常是串行执行的：每个优化阶段都在程序树表示上进行工作，并为下一阶段做好准备。在优化过程中，一个阶段中做出的每一个决策都可能会对未来的优化产生影响，并且通道可能以非平凡的方式相互作用，这可能很难预测。编译器使用不同的启发式方法来生成最优化的代码，但在某些情况下，这些启发式方法并不适用，如本例所示。

在本例中，似乎一切都按预期开始了。＜code＞-Os＜/code＞生成了更紧凑的中间代码，但这在以后会发生变化。GCC执行的第一个阶段是扩展阶段，它将GCC的高级树表示（称为GIMPLE）转换为低级RTL表示。它生成与以下类似的RTL代码：

O3：

1. tmp1

操作系统：

1. tmp

到目前为止，一切顺利-＜code＞-操作系统＜/code＞获胜。但之后，大约15个阶段之后，执行合并阶段，该阶段尝试将一系列指令合并为一条指令。对于＜code>-O3-Os，Combine做得不太好，无法进一步折叠代码。从这一点来看，进一步优化后代码不会有太大变化。

为了回答确切的问题 - 为什么GCC这样做（生成它在使用-O3扩展期间所做的代码，以及为什么Combine在-Os中做得不好），必须检查GCC代码并找出哪些GCC参数是有影响力的，以及前面的优化阶段做出的决策。

但是，问题是，虽然GCC在这个例子中表现不佳，但它可能是大多数其他例子的最佳选择。这是一个微妙的权衡问题——对于编译器编写者来说不是一件容易的工作！

这可能无法完全回答问题，但希望它能提供一些有用的背景知识。如果您有兴趣在每个优化阶段检查 GCC 的输出，则可以添加 -da 编译标志（它将为每个阶段生成带注释的树转储）和 -dP 标志（它将树注释添加到生成的程序集输出）和 -S。