编译器优化：GCC优化等级、-O2/-O3/-Os选择、LTO链接时优化、内联函数与属性

编译器优化，说白了就是让编译器帮你把代码“拧干水分”。我见过不少工程师，写完代码就往板子上一烧，跑起来就算完事。但你知道吗？同样的C代码，换个优化选项，性能可能差30%以上。这不是玄学，是实实在在的编译器魔法。

今天咱们就聊聊GCC的优化等级怎么选，LTO是什么鬼，以及内联函数和属性怎么用才不翻车。

GCC优化等级：从-O0到-Os

GCC的优化等级，我习惯把它分成四个档位：

优化等级	核心特点	适用场景	编译时间
-O0	不做优化，调试友好	开发调试阶段	最快
-O1	基础优化，平衡编译速度	快速验证	较快
-O2	大部分优化开启，不包含空间换时间	生产发布首选	中等
-O3	激进优化，包含向量化等	计算密集型	较慢
-Os	以代码体积为优先	Flash/RAM受限	中等

-O2 vs -O3：别盲目追求激进

很多人觉得-O3肯定比-O2快，其实不一定。我踩过一个坑：某次做音频处理，开了-O3，结果程序跑飞了。查了两天，发现是编译器把某个循环做了过度展开，导致栈溢出。

-O3相比-O2，主要多了这些优化：

• 自动向量化：把循环转换成SIMD指令
• 函数内联更激进：不管函数大小，能内联就内联
• 循环展开更积极：减少循环控制开销
• 重排序优化：改变指令执行顺序

-Os：空间换时间的反向操作

嵌入式系统里，Flash和RAM都是稀缺资源。我做过一个项目，芯片Flash只有64KB，代码编译出来65KB，差一点就装不下了。这时候-Os就是救命稻草。

-Os会做这些事：

• 优先使用短跳转指令
• 减少函数内联
• 复用公共子表达式
• 压缩常量池

但要注意，-Os可能会让性能下降10%-20%。如果你的系统对实时性要求高，得权衡一下。

LTO：链接时优化

LTO（Link Time Optimization）是个好东西。传统的优化是每个源文件单独做，链接器只管拼在一起。LTO不一样，它让链接器也参与优化。

举个例子：

// file1.c
int add(int a, int b) {
    return a + b;
}

// file2.c
extern int add(int, int);
int result = add(3, 4);

没有LTO时，编译器不知道add函数只在file2.c里用一次，所以不会内联。开了LTO，链接器能看到全局，直接把add函数内联到调用处，省了一次函数调用开销。

LTO的开启方式：

# 编译和链接都要加 -flto
gcc -c -O2 -flto file1.c
gcc -c -O2 -flto file2.c
gcc -O2 -flto file1.o file2.o -o program

内联函数：用得好是宝，用不好是草

内联函数，就是把函数调用替换成函数体本身。好处是省了调用开销，坏处是代码体积膨胀。

我见过有人把几百行的函数也加上inline，结果代码体积翻倍，性能反而下降——因为指令缓存命中率降低了。

什么时候该用内联？

• 函数体很小（3-5行）
• 被频繁调用（比如中断服务函数里的辅助函数）
• 对性能敏感的路径

什么时候别用？

• 函数体很大
• 调用次数很少
• 递归函数（编译器会忽略inline）

函数属性：给编译器更多线索

GCC提供了一些函数属性，可以告诉编译器更多信息，帮助它做更好的优化。

常用的几个：

属性	作用	示例
__attribute__((always_inline))	强制内联，不管函数多大	慎用，容易膨胀
__attribute__((noinline))	禁止内联	调试时有用
__attribute__((hot))	标记热点函数	编译器会优先优化
__attribute__((cold))	标记冷门函数	编译器会优化体积
__attribute__((const))	函数只依赖参数，无副作用	可消除重复调用
__attribute__((pure))	函数只读全局变量	比const宽松一点

举个例子：

// 告诉编译器这个函数很热，优先优化
__attribute__((hot))
int calculate_fft(int *data, int len) {
    // 大量计算
}

// 这个函数只依赖参数，可以消除重复调用
__attribute__((const))
int square(int x) {
    return x * x;
}

// 调用时，编译器会优化成一次调用
int a = square(5);
int b = square(5);  // 编译器知道结果一样，直接复用

知识体系总览

下面这张图，帮你理清编译器优化的核心脉络：

实战建议

说了这么多，总结几条我实际项目中的经验：

1. 开发阶段用-O0，调试方便，编译快。别在-O2下调试，优化后的代码和源码对应关系很乱。
2. 发布前用-O2跑一遍，看看功能是否正常。如果没问题，就定下来。
3. 只有确认性能瓶颈在CPU，才考虑-O3。而且要在关键模块单独开-O3，别全局开。
4. Flash吃紧时用-Os，但记得做性能测试。有些代码-Os后性能下降明显，需要手动优化。
5. LTO建议开启，尤其是项目有多个源文件时。编译慢一点，但运行快不少。
6. 函数属性别滥用，hot/cold可以加，const/pure要谨慎。