第三章 编译器优化入门：GCC优化等级与代码调优
编译器优化，说白了就是让工具帮你把代码改得更快、更省电。很多嵌入式工程师觉得这是编译器的家务事，跟自己没关系。我刚开始做项目时也这么想，直到有一次电池续航死活差30%，最后发现只是优化等级没选对——嗯，从那以后我再也不敢忽视编译器了。
3.1 GCC优化等级：-O0到-Os的差异
GCC的优化等级，本质上是编译器在「编译速度」和「运行效率」之间做的取舍。每个等级背后是一组独立的优化开关，我习惯把它们分成四个梯队：
| 优化等级 | 核心目标 | 典型场景 | 代码膨胀风险 |
|---|---|---|---|
| -O0 | 最快编译，不优化 | 调试、单步跟踪 | 无 |
| -O1 | 基础优化，平衡 | 开发阶段验证 | 低 |
| -O2 | 全面优化，性能优先 | 正式发布、性能敏感 | 中 |
| -Os | 优化代码体积 | Flash受限、低功耗 | 负（体积缩小） |
关键认知：-O2 不等于 -O1 + 更多优化。每个等级是独立优化集合，-O2 会启用一些可能改变代码语义的优化（比如严格别名分析），搞不好会踩坑。
我曾经在一个STM32项目上，用-O2编译一切正常，换成-Os后某个定时器中断就不响应了。查了两天才发现是-Os把某个volatile变量优化掉了——编译器觉得它没被修改，直接塞进寄存器。从那以后，我养成了一个习惯：关键外设寄存器变量，必须加 volatile，不管用哪个优化等级。
3.2 循环展开优化：用空间换时间
循环展开，就是把循环体复制多份，减少循环控制开销。你想想看，一个for循环每次都要判断 i < n、跳转回去，这些指令虽然小，但累积起来就是功耗。
手动展开的例子：
// 原始循环
for (int i = 0; i < 4; i++) {
buffer[i] = sensor_read(i);
}
// 手动展开
buffer[0] = sensor_read(0);
buffer[1] = sensor_read(1);
buffer[2] = sensor_read(2);
buffer[3] = sensor_read(3);展开后，循环控制指令从4次降为0次。但代价是代码体积变大——Flash多占几个字节。在低功耗场景下，这往往是划算的：少执行指令 = 少耗电。
我的经验：循环展开的收益在迭代次数小于8时最明显。超过16次后，代码膨胀带来的指令缓存缺失反而会拖慢速度。我一般控制在4~8次展开。
GCC的 -funroll-loops 开关可以自动做这件事。但要注意，编译器不一定总能判断出展开是否有利。我个人习惯在热点循环上手动展开，然后对比编译后的汇编确认效果。
3.3 函数内联优化：消除调用开销
函数调用是有成本的：压栈、跳转、返回、弹栈。对于小函数，调用开销可能比函数体本身还大。内联就是把函数体直接插入调用处，消除这些开销。
GCC用 inline 关键字建议内联，但最终决定权在编译器：
// 建议内联的小函数
static inline int clamp(int val, int min, int max) {
if (val < min) return min;
if (val > max) return max;
return val;
}
// 调用处
int result = clamp(raw_value, 0, 255);内联后，这段代码变成：
int result;
if (raw_value < 0) result = 0;
else if (raw_value > 255) result = 255;
else result = raw_value;没有调用、没有返回、没有栈操作。在中断服务函数或高频循环中，这种优化效果非常明显。
避坑指南：我曾经把一个200行的函数加了 inline，结果代码体积暴涨，反而因为指令缓存频繁失效导致性能下降。内联只适合小函数（一般建议不超过10条指令）。大函数内联是灾难。
3.4 知识体系：优化等级与代码调优的关系
下面这张图展示了本章的核心逻辑：从源码到最终二进制，编译器优化等级如何影响代码体积和执行效率，以及我们作为开发者可以在哪些环节介入。
3.5 实战建议：如何选择优化策略
根据我多年的项目经验，这里给出一套实用的选择流程：
- 开发阶段用 -O0：调试方便，变量都能看到，单步不会跳来跳去。
- 功能验证用 -O1：比 -O0 快不少，但代码行为基本不变。
- 性能调优用 -O2：正式发布的首选。注意检查 volatile 和严格别名问题。
- Flash紧张用 -Os：代码体积能缩小20%~40%，但性能会略低于 -O2。
- 热点代码手动优化：对关键循环做手动展开，对小函数加 inline。
核心原则：不要盲目追求高优化等级。在低功耗嵌入式系统中，-Os 往往比 -O2 更合适——代码小意味着指令缓存命中率高，取指令次数少，功耗自然低。
我记得有个低功耗传感器节点项目，用 -O2 时待机电流是 12μA，换成 -Os 后降到 8μA。原因就是代码体积缩小后，Flash读取次数减少，MCU在低功耗模式下唤醒时间更短。你看，有时候「慢一点」反而更省电。