gcc vs clang：使用 -fPIC 内联函数

Question

考虑这段代码：

// 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    , %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 问题？

Answer 1

我不认为该标准涉及那么多细节。它只是说，如果符号在不同的翻译单元中有外部链接，那么它就是同一个符号。这使得 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    [=10=]x1,%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    [=10=]x1,%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 来构建他的可执行文件，那么它会以一些开销为代价。

补充说明：

在来自一位 gcc 开发人员的 this blog entry 中，他提到，在 post 的末尾：

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 -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;
}

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

gcc vs clang：使用 -fPIC 内联函数

gcc vs clang: inlining a function with -fPIC

c++

gcc

clang

fpic