📚 课程目录第4章函数调用约定与ABI

4. 函数调用约定与ABI

函数调用，是程序里最频繁的操作之一。但每次调用背后，都有不小的代价——保存现场、分配栈帧、传参、返回。在 ARM64 上，这些开销如果累积起来，性能差距会非常明显。这一章，我带你逐个拆解这些优化点。

4.1 尾调用优化（Tail Call）

什么叫尾调用？说白了，就是一个函数的最后一步，调用了另一个函数。没有额外的计算，没有保存中间结果。这种情况下，编译器可以复用当前栈帧，直接跳转到目标函数。

核心收益：消除多余的栈帧分配，减少栈溢出风险，提升调用链性能。

我举个例子。假设你有这样一个递归函数：

// 非尾调用版本
int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);  // 最后一步是乘法，不是调用
}

这个版本，每次递归都要保留当前栈帧，因为返回后还要做乘法。n 大了，栈很容易爆。

改成尾调用：

// 尾调用版本
int factorial_tail(int n, int acc) {
    if (n <= 1) return acc;
    return factorial_tail(n - 1, n * acc);  // 最后一步就是调用
}

在 ARM64 上，编译器会生成类似这样的指令：

factorial_tail:
    cmp    w0, #1
    b.le   .Lreturn
    mul    w1, w0, w1      // acc = n * acc
    sub    w0, w0, #1      // n = n - 1
    b      factorial_tail  // 直接跳转，不压栈
.Lreturn:
    mov    w0, w1
    ret

看到了吗？b 指令直接跳转，没有 bl，没有 stp/ldp。栈帧完全复用。

我的经验：在嵌入式实时系统中，我经常用尾调用优化来避免栈溢出。有一次一个递归深度超过 2000 的算法，改成尾调用后，栈占用从 64KB 降到了 512 字节。效果立竿见影。

注意：尾调用优化需要编译器开启优化选项（如 -O2 或 -O3）。调试模式下（-O0），编译器通常不会做这个优化。另外，C 语言标准不强制要求尾调用优化，但 GCC/Clang 在 ARM64 上做得很好。

4.2 内联函数（Inline）

内联函数，就是把函数调用直接替换成函数体。省去了调用开销，但也增加了代码体积。这是个典型的「空间换时间」策略。

在 ARM64 上，内联的好处尤其明显：

消除调用指令：省去 bl 和 ret 的开销
消除栈帧操作：不需要保存/恢复寄存器
便于后续优化：编译器可以跨函数边界做常量传播、死代码消除

但也不是所有函数都适合内联。我总结了几条经验：

适合内联	不适合内联
短小函数（1-5 行）	大型函数（超过 50 行）
频繁调用的 getter/setter	递归函数
性能关键路径上的函数	虚函数（多态调用）
宏的替代品	函数指针调用的函数

举个例子：

// 适合内联
static inline int clamp(int val, int min, int max) {
    if (val < min) return min;
    if (val > max) return max;
    return val;
}

// 不适合内联
void process_large_data(struct data *d) {
    // 几百行处理逻辑
    // 内联会导致代码膨胀严重
}

我个人的习惯：先用 static inline 标记那些短小、频繁调用的函数。然后通过性能分析工具（perf）检查，如果发现某些函数调用开销占比过高，再考虑手动内联或调整内联策略。不要盲目给所有函数加 inline。

4.3 寄存器分配策略

ARM64 有 31 个通用寄存器（X0-X30），加上栈指针 SP。怎么用好这些寄存器，直接决定了函数调用的效率。

先看 ARM64 的调用约定（AAPCS64）：

寄存器	用途	调用者保存？
X0-X7	参数传递 / 返回值	调用者保存
X8	间接结果寄存器	调用者保存
X9-X15	临时寄存器	调用者保存
X16-X17	IP0, IP1（过程内调用临时）	调用者保存
X18	平台寄存器（一般不碰）	-
X19-X28	被调用者保存寄存器	被调用者保存
X29	帧指针（FP）	被调用者保存
X30	链接寄存器（LR）	被调用者保存

这里有个关键点：X0-X7 用于传参，X19-X28 是 callee-saved。如果你的函数需要大量局部变量，尽量用 X9-X15（caller-saved），避免压栈保存 X19-X28。

我曾经在项目中遇到过一个问题：一个函数用了 12 个局部变量，编译器被迫把 X19-X24 压栈保存。每次调用多出 48 字节的栈操作。后来我把函数拆成两个，每个函数只用 6 个局部变量，全部用 X9-X14 搞定，栈操作完全消除。性能提升了 15%。

寄存器分配策略总结：

优先使用 X0-X7 和 X9-X15（caller-saved）
减少局部变量数量，控制在 8 个以内
避免在频繁调用的函数中使用大量 callee-saved 寄存器
使用 register 关键字提示编译器（但现代编译器基本忽略）

4.4 减少栈帧开销

栈帧开销，说白了就是函数进入和退出时，保存/恢复寄存器和分配/释放栈空间的那部分指令。在 ARM64 上，典型的栈帧操作是这样的：

// 函数入口
stp    x29, x30, [sp, #-32]!   // 保存 FP 和 LR，分配 32 字节栈
stp    x19, x20, [sp, #16]     // 保存 callee-saved 寄存器
mov    x29, sp                 // 设置帧指针

// 函数体...

// 函数出口
ldp    x19, x20, [sp, #16]     // 恢复寄存器
ldp    x29, x30, [sp], #32     // 恢复 FP/LR，释放栈
ret

怎么减少这些开销？我总结了几个实战技巧：

使用叶子函数（Leaf Function）——不调用其他函数的函数。叶子函数不需要保存 LR，也不需要分配栈帧（如果局部变量少）。
省略帧指针——用 -fomit-frame-pointer 编译选项。这样函数不需要维护 X29（FP），省去两条指令。
合并栈分配——如果函数有多个局部变量，尽量一次性分配足够的栈空间，避免多次调整 SP。
使用寄存器传递参数——ARM64 有 8 个参数寄存器，尽量把参数控制在 8 个以内，避免压栈传参。

举个例子，对比两个版本：

// 版本 A：有栈帧开销
int add_and_multiply(int a, int b, int c) {
    stp    x29, x30, [sp, #-16]!
    mov    x29, sp
    add    w0, w0, w1
    mul    w0, w0, w2
    ldp    x29, x30, [sp], #16
    ret
}

// 版本 B：叶子函数，无栈帧
int add_and_multiply_leaf(int a, int b, int c) {
    // 编译器直接生成：
    add    w0, w0, w1
    mul    w0, w0, w2
    ret
}

版本 B 少了 4 条指令，每次调用省了 16 字节的栈操作。如果这个函数被调用 100 万次，省下的时间就很可观了。

我曾经踩过的坑：在调试版本中，默认开启了帧指针（-fno-omit-frame-pointer），导致所有函数都有栈帧操作。上线前忘记改成 release 编译选项，性能直接掉了 20%。所以，记得在 release 构建中加上 -O2 -fomit-frame-pointer。

知识结构图

下面这张图，把本章的四个优化方向串起来了。你可以看到它们之间的关系和优先级。

嗯，这张图把四个方向的关系理清楚了。你想想看，尾调用优化是「零成本」的——只要改改代码结构，编译器就能帮你搞定。内联函数需要权衡代码体积。寄存器分配和栈帧优化，更多是写代码时的习惯和编译选项的选择。

实战建议：

先检查你的递归函数，改成尾调用形式
对短小频繁的函数加 static inline
编译时加 -O2 -fomit-frame-pointer
用 perf 或 ARM Streamline 分析函数调用开销

这些优化技巧，我在多个项目中验证过。从嵌入式 RTOS 到 Android 系统服务，都能看到明显的性能提升。说白了，函数调用优化就是「积少成多」——每次省几条指令，调用次数多了，效果就出来了。