与一般内联相比，为什么 gnu_inline 属性对代码生成的影响如此之大？

Question

为什么使用extern inline __attribute__((gnu_inline)) 而不是static inline 会对GCC 8.3 代码生成产生如此大的影响？

The example code 基于 glibc bsearch 代码（使用 -O3 构建）：

#include <stddef.h>

extern inline __attribute__((gnu_inline))
void *bsearch (const void *__key, const void *__base, size_t __nmemb, size_t __size,
   int (*__compar)(const void *, const void *))
{
    size_t __l, __u, __idx;
    const void *__p;
    int __comparison;

    __l = 0;
    __u = __nmemb;
    while (__l < __u) {
        __idx = (__l + __u) / 2;
        __p = (void *) (((const char *) __base) + (__idx * __size));
        __comparison = (*__compar) (__key, __p);
        if (__comparison < 0)
            __u = __idx;
        else if (__comparison > 0)
            __l = __idx + 1;
        else
            return (void *) __p;
    }

  return NULL;
}

static int comp_int(const void *a, const void *b)
{
    int l = *(const int *) a, r = *(const int *) b;
    if (l > r) return 1;
    else if (l < r) return -1;
    else return 0;
}

int *bsearch_int(int key, const int *data, size_t num)
{
    return bsearch(&key, data, num, sizeof(int), &comp_int);
}

为bsearch_int函数生成的代码是：

bsearch_int:
        test    rdx, rdx
        je      .L6
        xor     r8d, r8d
.L5:
        lea     rcx, [rdx+r8]
        shr     rcx
        lea     rax, [rsi+rcx*4]
        cmp     DWORD PTR [rax], edi
        jl      .L3
        jg      .L10
        ret
.L10:
        mov     rdx, rcx
.L4:
        cmp     rdx, r8
        ja      .L5
.L6:
        xor     eax, eax
        ret
.L3:
        lea     r8, [rcx+1]
        jmp     .L4

如果我使用static inline 而不是extern inline __attribute__((gnu_inline))，我会得到更大的代码：

bsearch_int:
        xor     r8d, r8d
        test    rdx, rdx
        je      .L11
.L2:
        lea     rcx, [r8+rdx]
        shr     rcx
        lea     rax, [rsi+rcx*4]
        cmp     edi, DWORD PTR [rax]
        jg      .L7
        jl      .L17
.L1:
        ret
.L17:
        cmp     r8, rcx
        jnb     .L11
        lea     rdx, [r8+rcx]
        shr     rdx
        lea     rax, [rsi+rdx*4]
        cmp     edi, DWORD PTR [rax]
        jg      .L12
        jge     .L1
        cmp     r8, rdx
        jnb     .L11
.L6:
        lea     rcx, [r8+rdx]
        shr     rcx
        lea     rax, [rsi+rcx*4]
        cmp     DWORD PTR [rax], edi
        jl      .L7
        jle     .L1
        mov     rdx, rcx
        cmp     r8, rdx
        jb      .L6
.L11:
        xor     eax, eax
.L18:
        ret
.L12:
        mov     rax, rcx
        mov     rcx, rdx
        mov     rdx, rax
.L7:
        lea     r8, [rcx+1]
        cmp     r8, rdx
        jb      .L2
        xor     eax, eax
        jmp     .L18

是什么让 GCC 在第一种情况下生成如此短的代码？

注意事项：

• Clang 似乎不受此影响。

Answer 1

下面的答案是基于revision 2 of the question，而修订版 3 根据这个答案改变了问题的含义，之后下面的大部分答案似乎有点脱离上下文。根据第 2 版保留此答案。

---

来自6.31.1 Common Function Attributes of GCC's manual [强调我的]：

gnu_inline

此属性应与也声明的函数一起使用 使用 inline 关键字。它指示 GCC 将函数 视为 如果它是在 gnu90 模式下定义的，即使在 C99 或 gnu99 中编译 模式。

...

并且，来自Section 6.42 An Inline Function is As Fast As a Macro [强调我的]：

当一个函数同时是inline和static时，如果所有调用 函数被集成到调用者中，函数的地址为 从未使用过，则函数自己的汇编代码永远不会 参考。在这种情况下，GCC 并不实际输出汇编程序 函数的代码，除非您指定选项 -fkeep-inline-functions。

...

本节的其余部分特定于 GNU C90 内联。

当inline 函数不是static 时，编译器必须 假设可能有来自其他源文件的调用；由于全球 符号在任何程序中只能定义一次，函数不能 在其他源文件中定义，因此其中的调用不能 融合的。因此，一个非static inline 函数总是 以通常的方式自行编译。

如果您在函数中同时指定 inline 和 extern 定义，则定义仅用于内联。在没有 case 是自己编译的函数，即使你引用它 明确地址。这样的地址成为外部引用，如 如果你只声明了函数，而没有定义它。

...

这里的关键是gnu_inline 属性只会对以下两种情况产生影响，其中 GNU C90 内联将适用：

• 同时使用extern 和inline，并且
• 仅使用inline。

正如预期的那样，我们看到这两者之间生成的程序集存在很大差异。

但是，当使用 static 和 inline 时，GNU C90 内联规则不适用（或者更确切地说，没有专门涵盖这种情况），这意味着 gnu_inline 属性无关紧要。

确实，这两个签名导致相同的程序集：

static inline __attribute__((gnu_inline))
void *bsearch ...

static inline
void *bsearch ...

由于extern inline 和static inline 使用两种不同的内联方法（分别是GNU C90 内联策略和更现代的内联策略），因此可以预期生成的程序集在这两者之间可能会略有不同。尽管如此，与仅使用 inline 时相比，这两者产生的汇编输出要少得多（在这种情况下，如上所述，该函数始终是自行编译的）。

Answer 2

它只编译是因为你没有使用任何优化并且内联没有激活。例如，尝试使用 -O1，您的代码将根本无法编译。

代码不同，因为当您使用静态时，编译器不必关心调用约定，因为该函数对其他编译单元不可见。