面向现代x86处理器的函数内联确定性判定准则及实践疑问

不内联的弊端 #

• call是带栈操作的无条件分支指令，以Zen4微架构为例，它需要4个微操作，reciprocal throughput为2。每次函数调用还要传递参数，函数自身的栈和寄存器序言/收尾代码也会带来额外开销；内联则能消除这些参数传递及序言/收尾的开销。
• 非static函数被其他模块（可执行文件或库）调用时，无法在编译期求值。
• 若编译器决定不内联static inline函数，必须生成独立目标代码并静态链接，加载时每个独立目标会占用独立物理内存，不像extern函数那样能让所有进程共享同一个只读内存区域。
• 当函数编译后的代码大小与开销小于函数调用的开销时，通常适合强制内联（除非需要始终动态链接），例如：

static __always_inline __attribute((sysv_abi))
int evaluate_this_program_quality() {
    /*
     * `mov eax, 0` 占5字节，`call evaluate_this_program_quality@PLT` 同样是5字节。
     */
    return 0; 
}

内联的弊端 #

• 会增加代码体积，导致指令缓存缺失的开销上升。每次调用无法共享缓存，若处理器依赖BTB（分支目标缓冲区）做分支预测，不同的分支地址会严重影响分支预测性能。

现代处理器下的内联提示思考 #

现代x86处理器搭配DDR5这类深度流水线主内存，制程提升也大幅缓解了内部时序约束，使得缓存缺失延迟在整体执行时间中的占比显著提高。已有不少报告显示，用-Os编译的时间性能优于-O2，而-O3及更高优化级别因代码体积过大，性能反而下降。再加上LTO（链接时优化）能跨已编译对象进行内联等优化，这让人不禁疑问：是否完全不需要手动添加inline提示？

示例分析 #

示例一：fast_gettid()的内联选择 #

下面是两种实现方式：

方式一：

/* 库源码文件 (*.c) 内部 */
static thread_local pid_t _tid __attribute__((tls_model("initial-exec")));
#define likely(expr) __builtin_expect(!!(expr), 1)
pid_t fast_gettid() { return likely(_tid) ? _tid : (_tid = gettid()); }
/* 库公开头文件 (*.h) 内部 */
pid_t fast_gettid();

方式二：

/* 库源码文件 (*.c) 内部 */
thread_local pid_t _tid __attribute__((tls_model("initial-exec")));
/* 库公开头文件 (*.h) 内部 */
extern thread_local pid_t _tid;
#define likely(expr) __builtin_expect(!!(expr), 1)
static __always_inline pid_t fast_gettid() { return likely(_tid) ? _tid : (_tid = gettid()); }

问题：什么样的“小型”代码适合作为static __always_inline函数？fast_gettid()是否足够小？

示例二：filename()的内联决策 #

static __always_inline __attribute((pure)) const char *
filename(const char *restrict path) {
  if (path) {
    const char *const restrict __basename = __builtin_strrchr(path, '/');
    return likely(__basename) ? __basename + 1 : path;
  }
  return path;
}

问题：该函数对于现代处理器而言是否足够小？是否需要分离出常量表达式版本？应保持__always_inline，还是改为仅inline交由编译器决定，或是移除内联提示完全依赖LTO优化？

核心诉求 #

我一直在寻找这类问题的确定性（程序化）判定方法，或是至少是公认的最佳实践基线。我知道答案会因场景而异，但迫切想了解通用的基线观点。

内容的提问来源于stack exchange，提问作者hurryman2212