考虑这段代码:

// foo.cxx
int last;

int next() {
  return ++last;
}

int index(int scale) {
  return next() << scale;
}

使用 gcc 7.2 编译时:

$ g++ -std=c++11 -O3 -fPIC

这发出:

next():
    movq    last@GOTPCREL(%rip), %rdx
    movl    (%rdx), %eax
    addl    $1, %eax
    movl    %eax, (%rdx)
    ret
index(int):
    pushq   %rbx
    movl    %edi, %ebx
    call    next()@PLT    ## next() not inlined, call through PLT
    movl    %ebx, %ecx
    sall    %cl, %eax
    popq    %rbx
    ret

但是，当使用 clang 3.9 编译具有相同标志的相同代码时:

next():                               # @next()
    movq    last@GOTPCREL(%rip), %rcx
    movl    (%rcx), %eax
    incl    %eax
    movl    %eax, (%rcx)
    retq

index(int):                              # @index(int)
    movq    last@GOTPCREL(%rip), %rcx
    movl    (%rcx), %eax
    incl    %eax              ## next() was inlined!
    movl    %eax, (%rcx)
    movl    %edi, %ecx
    shll    %cl, %eax
    retq

gcc 通过 PLT 调用 next()，clang 将其内联。两者仍然从 GOT 中查找 last。对于在 Linux 上编译，clang 进行优化是否正确并且 gcc 错过了简单的内联，或者 clang 进行优化是错误的，还是这纯粹是 QoI 问题？

最佳答案

我不认为该标准涉及那么多细节。它只是说，如果符号在不同的翻译单元中有外部链接，那么它就是同一个符号。这使得 clang 的版本正确。

从那时起，据我所知，我们超出了标准。编译器的选择因他们认为有用的 -fPIC 输出而异。

请注意 g++ -c -std=c++11 -O3 -fPIE 输出:

0000000000000000 <_Z4nextv>:
   0:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 6 <_Z4nextv+0x6>
   6:   83 c0 01                add    $0x1,%eax
   9:   89 05 00 00 00 00       mov    %eax,0x0(%rip)        # f <_Z4nextv+0xf>
   f:   c3                      retq   

0000000000000010 <_Z5indexi>:
  10:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 16 <_Z5indexi+0x6>
  16:   89 f9                   mov    %edi,%ecx
  18:   83 c0 01                add    $0x1,%eax
  1b:   89 05 00 00 00 00       mov    %eax,0x0(%rip)        # 21 <_Z5indexi+0x11>
  21:   d3 e0                   shl    %cl,%eax
  23:   c3                      retq

所以 GCC 确实知道如何优化它。它只是在使用 -fPIC 时选择不这样做。但为什么？我只能看到一种解释:使在动态链接期间覆盖符号成为可能，并始终如一地看到效果。该技术被称为 symbol interposition .

在共享库中，如果index调用next，因为next是全局可见的，gcc必须考虑的可能性next 可以插入。所以它使用PLT。但是，当使用 -fPIE 时，不允许插入符号，因此 gcc 启用了优化。

那么clang错了吗？不，但是 gcc 似乎为符号插入提供了更好的支持，这对于检测代码很方便。但是，如果使用 -fPIC 而不是 -fPIE 来构建他的可执行文件，那么它会以一些开销为代价。

补充说明:

在this blog entry来自一位 gcc 开发人员，他在帖子末尾提到:

While comparing some benchmarks to clang, I noticed that clang actually ignore ELF interposition rules. While it is bug, I decided to add -fno-semantic-interposition flag to GCC to get similar behaviour. If interposition is not desirable, ELF's official answer is to use hidden visibility and if the symbol needs to be exported define an alias. This is not always practical thing to do by hand.

跟随那条线索，我登上了 x86-64 ABI spec .在第 3.5.5 节中，它确实强制要求所有调用全局可见符号的函数都必须通过 PLT(它根据内存模型定义要使用的确切指令序列)。

因此，尽管它没有违反 C++ 标准，但忽略语义插入似乎违反了 ABI。

最后一句话:不知道把它放在哪里，但你可能会感兴趣。我会为您省去转储，但我对 objdump 和编译器选项的测试表明:

在 gcc 方面:

• gcc -fPIC: 访问 last 通过 GOT，调用 next() 通过 PLT .
• gcc -fPIC -fno-semantic-interposition:last 通过 GOT，next() 是内联。
• gcc -fPIE: last 是 IP 相关的，next() 是内联的。
• -fPIE 表示 -fno-semantic-interposition

在 clang 方面:

• clang -fPIC: last 通过 GOT，next() 内联。
• clang -fPIE: last 通过 GOT，next() 内联。

以及一个编译为 IP 相关的修改版本，在两个编译器上内联:

// foo.cxx
int last_ __attribute__((visibility("hidden")));
extern int last __attribute__((alias("last_")));

int __attribute__((visibility("hidden"))) next_()
{
  return ++last_;
}
// This one is ugly, because alias needs the mangled name. Could extern "C" next_ instead.
extern int next() __attribute__((alias("_Z5next_v")));

int index(int scale) {
  return next_() << scale;
}

基本上，这明确表示尽管它们在全局范围内可用，但我们使用这些符号的隐藏版本，将忽略任何类型的插入。然后，无论传递的选项如何，两个编译器都会完全优化访问。

关于c++ - gcc 与 clang : inlining a function with -fPIC，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45971091/