1972年，David Gries在《Compiler Construction for Digital Computers》中描述了一个看似简单的优化：把被调用函数的代码直接复制到调用点。五十年后，这个"复制粘贴"技术仍然是编译器优化中最关键、最复杂，也最容易被误解的一环。
当你写下inline关键字时，编译器真的会听你的吗？当你什么都没写时，编译器凭什么决定要不要内联？为什么同样的代码在-O2和-O3下行为完全不同？这些问题背后，是一个涉及成本模型、缓存行为、指令调度和硬件特性的复杂决策系统。
一个函数调用到底要花多少代价
在讨论内联之前，先搞清楚为什么要内联——一个函数调用究竟有什么开销？
; x86-64 函数调用序列（简化）
push rbp ; 保存旧栈帧指针
mov rbp, rsp ; 设置新栈帧指针
sub rsp, 32 ; 分配局部变量空间
mov [rbp-8], rdi ; 保存第一个参数
mov [rbp-16], rsi ; 保存第二个参数
call callee ; 调用目标函数
add rsp, 32 ; 清理栈空间
pop rbp ; 恢复栈帧指针
ret ; 返回
一个看似简单的函数调用，在现代CPU上实际执行的指令远不止call这一条。下图展示了函数调用的完整开销构成：
pie showData
title 函数调用开销构成（Intel Skylake）
"寄存器保存恢复" : 3
"栈帧建立销毁" : 2
"参数传递" : 2
"指令缓存失效" : 5
"分支预测开销" : 3
按照Intel优化手册的数据，一次函数调用的开销包括：
-
寄存器保存与恢复：调用者保存寄存器（caller-saved）可能需要压栈，被调用者保存寄存器（callee-saved）在函数内部需要保存。x86-64 ABI规定
rax, rcx, rdx, rsi, rdi, r8-r11为caller-saved，rbx, rbp, r12-r15为callee-saved。 -
栈帧建立与销毁：即使没有局部变量，也需要维护栈帧链。
-
参数传递：前六个整数/指针参数通过寄存器传递，超过的部分压栈。浮点数通过XMM寄存器传递。
-
指令缓存失效：跳转到新地址可能导致指令缓存未命中。
-
分支预测器压力：函数返回地址的预测需要RAS（Return Address Stack）支持。
这些开销加起来，在Intel Skylake架构上大约是5-15个时钟周期的"纯调用开销"。但问题在于，这还不包括间接成本：
int add(int a, int b) {
return a + b;
}
int compute(int x, int y) {
return add(x, y) * 2;
}
如果不内联，编译器在compute中看到的是一次函数调用。如果内联，编译器看到的是(x + y) * 2——这开启了进一步优化的可能：
// 内联后可能优化为
int compute(int x, int y) {
return (x + y) << 1; // 乘2变成左移
}
这就是内联的核心价值：它不只是消除调用开销，更是让后续优化成为可能。常量传播、死代码消除、循环不变量外提——这些优化只有在函数边界被打破后才能生效。
编译器如何决定是否内联
既然内联这么好，为什么不把所有函数都内联？因为代码膨胀。一个被调用100次的函数，如果内联，代码量会增加100倍。
编译器的内联决策是一个典型的成本-收益分析问题。下图展示了编译器决策的核心流程：
flowchart TD
A[函数调用点] --> B[计算内联成本]
B --> C[计算内联收益]
C --> D{成本 < 收益?}
D -->|是| E[执行内联]
D -->|否| F[保持调用]
E --> G{达到增长限制?}
G -->|是| F
G -->|否| H[继续分析下一个调用点]
F --> H
以LLVM为例，其内联器使用以下成本模型：
// LLVM InlineCost.cpp（简化）
int computeInlineCost(CallBase &CB) {
int Cost = 0;
// 基础成本：每条指令 +1
for (Instruction &I : *Callee) {
Cost += getInstructionCost(I);
}
// 参数传递收益：每个参数 -1
Cost -= Callee->arg_size();
// 简单函数奖励
if (isSimpleFunction(Callee))
Cost -= LastCallToStaticBonus;
// 递归函数惩罚
if (Callee->hasFnAttribute(Attribute::NoRecurse))
Cost -= NoRecurseBonus;
return Cost;
}
这个简化模型揭示了内联决策的几个关键因素：
1. 函数大小是最核心的因素
LLVM用"指令数"来衡量函数大小，但不是简单的指令计数。不同指令的权重不同：
int getInstructionCost(Instruction &I) {
switch (I.getOpcode()) {
case Instruction::PHI: return 0; // PHI节点成本为0
case Instruction::Ret: return 0; // 返回指令成本为0
case Instruction::Call: return 5; // 函数调用成本较高
case Instruction::Load: return 3; // 内存访问成本中等
default: return 1; // 普通指令成本为1
}
}
PHI节点和返回指令成本为0，因为它们在内联后可能被优化掉。函数调用成本高，因为内联它可能开启进一步的内联。
2. 调用频率决定优先级
一个被调用1000次的小函数，和一个被调用1次的中等函数，哪个更应该内联？答案是后者——因为前者即使不内联，调用开销也只占总运行时间的一小部分。
这就是为什么编译器需要Profile-Guided Optimization (PGO)：
# GCC PGO 工作流
gcc -fprofile-generate program.c -o program
./program [训练输入]
gcc -fprofile-use program.c -o program_optimized
PGO会告诉编译器每个函数的实际调用频率：
// 编译器看到的原始代码
void process(int *data, int n) {
for (int i = 0; i < n; i++) {
data[i] = transform(data[i]); // transform应该内联吗？
}
}
// PGO告诉编译器：transform被调用了1000万次
// 编译器决策：transform太小了，必须内联，消除调用开销是关键
3. 常量传播带来的收益
如果调用点能提供常量参数，内联收益会大幅增加：
int power(int base, int exp) {
int result = 1;
for (int i = 0; i < exp; i++)
result *= base;
return result;
}
// 调用点
int x = power(2, 10); // 如果内联，编译器能直接算出1024
LLVM会给这类调用点额外的"奖励分"，因为它知道内联后常量传播会生效。
4. 单一调用点的特殊情况
如果函数只在一个地方被调用，内联几乎是必然的：
static int helper(int x) { // 只在compute中调用
return x * 2 + 1;
}
int compute(int y) {
return helper(y) + helper(y + 1);
}
内联helper后，它的代码可以完全消失——没有人再需要调用它了。这反而可能减少代码量。2021年的一项研究显示，这类"孤立调用内联"平均能减少2.5%的代码大小。
不同编译器的内联策略
主流编译器的内联策略差异巨大，下图对比了不同编译器的决策特点：
quadrantChart
title 编译器内联策略对比
x-axis "保守" --> "激进"
y-axis "静态决策" --> "动态决策"
quadrant-1 "激进动态"
quadrant-2 "保守动态"
quadrant-3 "保守静态"
quadrant-4 "激进静态"
"Go": [0.2, 0.1]
"GCC": [0.4, 0.2]
"LLVM": [0.6, 0.3]
"JVM HotSpot": [0.7, 0.9]
"Rust (LLVM)": [0.6, 0.3]
GCC：基于增长限制的保守策略
GCC的内联器是编译器工程中的经典实现。它的核心策略是代码增长限制：
# GCC 内联相关参数
--param max-inline-insns-single=500 # 单调用点函数的最大指令数
--param max-inline-insns-auto=50 # 多调用点函数的最大指令数
--param inline-unit-growth=30 # 允许的总体代码增长百分比
--param max-inline-insns-recursive=400 # 递归内联的最大指令数
GCC首先对函数调用点按"优先级"排序，然后按顺序内联，直到达到增长限制。优先级计算公式为：
$$Priority = \frac{Benefit}{Cost}$$其中Benefit包括调用频率、常量传播潜力、参数寄存器化收益；Cost主要是函数大小。
LLVM：更精细的成本模型
LLVM的内联器比GCC更复杂。它不使用简单的指令计数，而是为每条指令分配"成本"：
; LLVM IR 示例
define i32 @add(i32 %a, i32 %b) {
%sum = add i32 %a, %b ; 成本: 1
ret i32 %sum ; 成本: 0
}
LLVM还实现了部分内联（Partial Inlining），这是GCC没有的特性：
// 原始函数
int process(int x) {
if (x < 0) {
// 冷路径：复杂的错误处理
log_error(x);
return -1;
}
// 热路径：简单计算
return x * 2;
}
// 部分内联后
int process(int x) {
if (x < 0) goto process.cold; // 冷路径外提
return x * 2; // 热路径内联
}
process.cold:
log_error(x);
return -1;
这种技术让编译器能"吃掉蛋糕又拥有蛋糕"——内联热路径获得性能收益，同时保持冷路径共享避免代码膨胀。
JVM：运行时决策与去优化
JVM的内联策略完全不同。因为JIT编译发生在运行时，HotSpot能看到真实的调用频率：
public class Example {
private int add(int a, int b) {
return a + b;
}
public int compute(int x) {
int sum = 0;
for (int i = 0; i < 1000000; i++) {
sum += add(x, i); // JVM观察到：add被调用100万次
}
return sum;
}
}
JVM的内联决策流程与静态编译器截然不同：
flowchart TD
A[方法被调用] --> B{调用次数 > 阈值?}
B -->|否| C[解释执行]
B -->|是| D{是热点方法?}
D -->|否| C
D -->|是| E[C1编译器快速编译]
E --> F{调用次数 > 更高阈值?}
F -->|否| G[执行C1代码]
F -->|是| H[C2编译器深度优化]
H --> I[内联热路径]
I --> J{假设被打破?}
J -->|否| K[继续执行优化代码]
J -->|是| L[去优化]
L --> C
JVM的内联决策包括：
-
热点检测：只有"热"方法才会被JIT编译和内联。默认阈值是1500次调用（C1编译器）或10000次调用（C2编译器）。
-
大小限制：C2编译器默认内联小于35字节节码的方法（可调整）。
-
虚方法处理：对于虚方法调用，JVM使用类型反馈来猜测实际类型：
interface Processor {
int process(int x);
}
class FastProcessor implements Processor {
public int process(int x) { return x * 2; }
}
// JVM观察到：processor总是FastProcessor实例
// 决策：去虚拟化 + 内联
- 去优化机制：如果JVM的内联假设被打破，它会"去优化"：
// JVM基于类型profile内联了FastProcessor.process
// 但后来出现了SlowProcessor实例...
processor = new SlowProcessor(); // 触发去优化！
// JVM丢弃优化代码，回到解释执行，重新收集profile
这是JVM内联与静态编译器最大的不同：它能冒险做出假设性内联，然后动态修正错误。
Go：极简主义的保守策略
Go编译器的内联策略以保守著称。在Go 1.9之前，只有叶子函数（不调用其他函数的函数）才能内联。Go 1.9引入了中栈内联（Mid-stack Inlining），但仍然非常谨慎：
// Go 内联决策规则（简化）
// 1. 函数AST节点数 < 80
// 2. 不包含复杂控制流（goto、defer）
// 3. 不是go或defer的目标
// 4. 不是runtime函数
Go的内联成本预算大约是80个AST节点。这听起来很苛刻，但Go团队有他们的理由：
“We’ve found that most inlining benefits come from small, leaf functions. Aggressive inlining rarely helps Go programs.” — Dave Cheney, Go contributor
Go团队发现，Go程序的函数调用开销在总执行时间中占比很小。原因之一是Go的函数调用经过精心优化：
; Go 函数调用（无栈帧开销）
TEXT ·add(SB), NOSPLIT, $0-24
MOVQ a+0(FP), AX
ADDQ b+8(FP), AX
MOVQ AX, ret+16(FP)
RET
Go函数默认不建立栈帧（除非必要），参数通过栈传递（无寄存器保存开销），这让调用成本变得很低。
Rust：交给LLVM决策
Rust本身不做内联决策，它将这个任务完全交给LLVM后端。Rust提供的#[inline]属性实际上是给LLVM的"建议"：
// 强烈建议内联（但LLVM可以拒绝）
#[inline(always)]
fn add(a: i32, b: i32) -> i32 {
a + b
}
// 建议不要内联（但LLVM可以忽略）
#[inline(never)]
fn complex_logic(x: i32) -> i32 {
// ...很多代码...
}
// 普通建议（默认）
#[inline] // 等同于不写，LLVM自己决定
fn normal(x: i32) -> i32 {
x + 1
}
Rust团队的经验是：开发者通常不知道什么应该内联。LLVM的启发式算法在大多数情况下比人类直觉更准确。
内联的反面：代码膨胀
2015年，一篇名为《There Are No Zero-Cost Abstractions》的CppCon演讲引发震动。Chandler Carruth展示了这样一个案例：
// 看似无害的抽象
template <typename F>
void for_each(std::vector<int>& v, F f) {
for (auto& x : v) f(x);
}
// 使用
std::vector<int> data = {1, 2, 3, 4, 5};
for_each(data, [](int& x) { x *= 2; });
这会被内联成什么？
// 内联后
for (auto& x : data) {
x *= 2;
}
看起来很好，对吧？但如果for_each被调用100次，每次传入不同的lambda，会怎样？
100个for_each实例。虽然每个实例很小，但它们加起来可能占用大量指令缓存。
指令缓存：隐藏的性能杀手
现代CPU的L1指令缓存很小——Intel Skylake只有32KB。当代码膨胀到超出这个范围，性能会断崖式下降：
// 不内联：紧凑的循环
for (int i = 0; i < N; i++) {
result[i] = process(data[i]); // 5字节调用指令
}
// 内联后：代码膨胀
for (int i = 0; i < N; i++) {
// process的100字节代码展开在这里
// 循环体从5字节变成105字节
}
如果process的100字节代码让循环体超出指令缓存行边界，每次循环迭代都可能触发缓存未命中。这比函数调用开销昂贵得多。
下图展示了代码大小与指令缓存命中率的关系：
xychart-beta
title "代码大小 vs L1指令缓存命中率"
x-axis ["8KB", "16KB", "24KB", "32KB", "40KB", "48KB", "56KB"]
y-axis "缓存命中率" 0 --> 100
line [98, 97, 96, 94, 85, 70, 55]
量化代码膨胀的影响
2010年的一项研究使用AdaBoost算法自动学习内联启发式，发现了一个反直觉的结论：
“在SPEC CPU 2006基准测试中，LLVM默认内联策略平均增加17%的代码大小，但只带来0.7%的性能提升。而我们训练的代码大小优化策略减少2.6%的代码，同时保持了相近的性能。”
这暗示着：现代CPU上的函数调用开销并没有想象中那么大。CPU的分支预测器对函数返回有专门的支持（Return Address Stack），指令预取器也能有效处理调用指令。真正重要的是指令缓存的局部性。
高级内联技术
部分内联与函数外提
前面提到过，这是LLVM的独特能力。更具体地说，部分内联的工作流程是：
flowchart TD
A[分析函数的执行路径] --> B[识别热路径/冷路径]
B --> C{冷路径大小 > 阈值?}
C -->|是| D[将冷路径外提为新函数]
C -->|否| E[保持原样]
D --> F[内联热路径到调用点]
F --> G[调用点保留对冷路径函数的调用]
实际例子：
// 原始代码
int find_element(int *arr, int n, int target) {
for (int i = 0; i < n; i++) {
if (arr[i] == target) {
// 冷路径：找到目标后的复杂处理
log_found(i, target);
send_notification(target);
update_stats(i);
return i;
}
}
// 热路径：没找到
return -1;
}
// 部分内联后（在调用点展开热路径）
int find_element$hot(int *arr, int n, int target) {
for (int i = 0; i < n; i++) {
if (arr[i] == target) {
return find_element$cold(i, target); // 调用外提的冷路径
}
}
return -1;
}
Profile-Guided优化
PGO是目前最有效的内联优化手段。它的工作原理：
flowchart LR
A[源代码] --> B[插桩编译]
B --> C[运行训练负载]
C --> D[收集执行profile]
D --> E[带profile的优化编译]
E --> F[最终可执行文件]
PGO提供的关键信息：
- 调用频率：每个调用点被触发的次数
- 分支概率：if/else各分支的执行比例
- 调用目标分布：虚调用的实际类型分布
这些信息让编译器能做出精确的内联决策：
// 无PGO时编译器的假设
void process(int x) {
if (x > 0) {
// 编译器假设：50%概率
handle_positive(x);
} else {
handle_non_positive(x);
}
}
// PGO告诉编译器：99.9%的情况下x > 0
// 决策：积极内联handle_positive，延迟处理handle_non_positive
机器学习驱动的内联决策
Google的MLGO项目（2022年）使用强化学习来优化LLVM的内联决策：
flowchart TD
A[调用点特征向量] --> B[策略网络]
B --> C{内联决策}
C -->|内联| D[执行内联]
C -->|不内联| E[保持调用]
D --> F[编译执行]
E --> F
F --> G[测量性能]
G --> H[计算奖励]
H --> I[更新策略网络]
I --> B
MLGO的简化概念模型：
class InliningPolicy:
def decide(self, call_site_features):
# 特征包括：
# - 调用者/被调用者大小
# - 调用深度
# - 常量参数数量
# - 循环嵌套深度
# - ...
# 神经网络决策
action = self.policy_network(call_site_features)
return action # 0: 不内联, 1: 内联
MLGO在Chrome浏览器上的测试显示，使用ML驱动的内联决策后，二进制大小减少了5.3%，同时性能没有损失。
什么时候不应该内联
1. 递归函数
int fibonacci(int n) {
if (n <= 1) return n;
return fibonacci(n - 1) + fibonacci(n - 2);
}
内联递归函数会导致无限展开。编译器需要检测这种模式并拒绝内联。
2. 极大的函数
void massive_function() {
// 10000行代码...
}
即使只调用一次，内联这么大的函数也会破坏指令缓存局部性。
3. 函数指针和虚函数（无类型信息时）
void call_via_pointer(void (*f)(int), int x) {
f(x); // 编译时不知道f指向什么，无法内联
}
4. 热路径已饱和的函数
如果一个函数95%的时间都在执行一个紧凑的循环，内联外层函数不会带来收益：
void process_array(int *arr, int n) {
setup(); // 5%时间
for (int i = 0; i < n; i++) { // 95%时间
arr[i] *= 2; // 这个循环才是瓶颈
}
cleanup(); // 忽略不计
}
内联process_array不会加速那个循环——它已经在那里了。
内联与调试的复杂关系
内联会显著影响调试体验：
int compute(int x) {
return add(x, 1); // 内联后，add的代码消失
}
如果add被内联，调试器在add中设置的断点不会触发，变量x（add的参数）也不可见。
现代编译器通过DWARF调试信息解决这个问题：
!llvm.dbg.cu = !{!0}
!0 = distinct !DICompileUnit(...)
!1 = distinct !DISubprogram(name: "add", ...)
!2 = !DILocation(line: 1, column: 12, scope: !1, inlinedAt: !3)
!3 = distinct !DILocation(line: 5, column: 10, scope: !4)
这段调试信息告诉调试器：“这里有一条来自add函数第1行的指令，但它被内联到了compute函数的第5行”。
不过，过度内联仍然会让单步调试变成噩梦——一行代码对应多个内联函数的代码，变量作用域混乱。
内联的未来
1. 链接时优化（LTO）的普及
传统内联受限于编译单元边界。LTO让编译器能看到整个程序：
# 传统编译：每个.c文件独立编译
gcc -c file1.c -o file1.o
gcc -c file2.c -o file2.o
gcc file1.o file2.o -o program
# LTO：链接时再做内联
gcc -flto -c file1.c -o file1.o
gcc -flto -c file2.c -o file2.o
gcc -flto file1.o file2.o -o program
LTO让file1中的函数可以内联到file2中，突破了编译单元的限制。
2. 动态内联
JVM展示了动态内联的威力。未来，AOT编译器可能会结合运行时profile进行迭代优化：
第一次编译：保守内联
↓
运行 + 收集profile
↓
第二次编译：激进内联热路径
3. 异构计算的内联
GPU/OpenCL代码的内联策略与CPU代码完全不同。GPU上函数调用开销更高（跨warp同步），内联收益更大。现代编译器正在发展针对异构平台的不同内联策略。
写给开发者的建议
-
别加
inline关键字：除非你确定自己在做什么。现代编译器的内联决策通常比你更准确。 -
关注热点：如果profiler显示某个函数是瓶颈，考虑重构让内联更容易（减少间接调用，减少虚函数）。
-
使用PGO：对于性能关键的应用，PGO带来的收益通常超过任何手动优化。
-
保持函数小巧：小函数更容易被内联，也更有可能被优化掉。
-
避免过早优化：内联是编译器的工作，不是开发者的工作。先让代码正确、清晰，再让编译器做它的事。
内联不是银弹，它是一种权衡。理解这种权衡的本质，才能写出真正高效的代码。
参考文献
- Lopes, N. P. (2010). Boosting Inlining Heuristics. CGO 2013.
- Pacheco, V. S. et al. (2021). Inlining for Code Size Reduction. SBLP 2021.
- Theodoridis, T. et al. (2022). Understanding and Exploiting Optimal Function Inlining. ASPLOS 2022.
- Cheney, D. (2020). Mid-stack inlining in Go. dave.cheney.net.
- Google. (2022). MLGO: A Machine Learning Framework for Compiler Optimization. research.google.
- Carruth, C. (2015). There Are No Zero-Cost Abstractions. CppCon 2019.
- OpenJDK. HotSpot JVM Performance Techniques Wiki.
- LLVM Project. InlineCost Analysis Implementation.
- GCC Manual. Optimizer Options.
- Godbolt, M. (2025). Partial Inlining. xania.org.