4. 编译器优化：GCC优化等级、-O2/-O3选择、LTO链接时优化
说到编译器优化，我见过不少工程师一上来就开-O3，觉得优化等级越高越好。其实没那么简单。今天咱们就聊聊GCC的优化等级怎么选，以及LTO这个“黑科技”到底能带来什么。
4.1 GCC优化等级：从-O0到-Os
GCC的优化等级，说白了就是告诉编译器：“你帮我多动动脑子，把代码整得高效点。”但编译器动脑子也是要花时间的，而且有时候它“自作聪明”反而会出问题。
常见的优化等级有这么几个：
| 优化等级 | 特点 | 典型场景 |
|---|---|---|
| -O0 | 不做优化，编译最快，调试最友好 | 开发调试阶段 |
| -O1 | 基础优化，平衡编译速度和代码质量 | 快速验证 |
| -O2 | 较激进优化，不包含空间换时间的技巧 | 产品发布首选 |
| -O3 | 更激进优化，可能包含循环展开等 | 计算密集型场景 |
| -Os | 以代码体积为优先 | Flash紧张的MCU |
我个人习惯，开发阶段用-O0，调试方便。到了要发布固件的时候，再切到-O2。为什么不是-O3？别急，后面会讲。
4.2 -O2 vs -O3：怎么选？
很多新手觉得-O3肯定比-O2强。其实不然。我在项目中遇到过好几次，开了-O3之后程序跑飞了，或者某些功能不正常了。
为什么会这样？因为-O3会启用一些比较“大胆”的优化，比如：
- 循环展开：把循环体复制多份，减少循环控制开销
- 函数内联：把短函数直接嵌入调用处
- 向量化：尝试用SIMD指令并行处理数据
这些优化在理论上能提升性能，但代价是代码体积变大，而且可能暴露一些潜在的bug。比如你写了个volatile变量，编译器在-O3下可能就把它优化掉了，导致时序出问题。
我的建议：
- 点钞机这种对稳定性要求极高的设备，优先用-O2
- 如果确实需要-O3，一定要做充分的压力测试
- 可以针对单个文件开-O3，而不是全局开启
嗯，这里要注意：点钞机的图像处理算法，如果计算量特别大，可以考虑把那个.c文件单独用-O3编译。其他模块保持-O2，这样既安全又高效。
4.3 LTO：链接时优化
LTO（Link Time Optimization）是个好东西。传统的编译是每个.c文件单独编译，生成目标文件，最后链接。这样有个问题：编译器看不到跨文件的优化机会。
举个例子：你在a.c里定义了一个函数，在b.c里调用它。如果没有LTO，编译器只能各自为战。有了LTO，链接器会把所有中间表示（IR）合并在一起，再做一次全局优化。
LTO能带来什么好处？
- 跨文件内联：把a.c的小函数内联到b.c的调用处
- 死代码消除：去掉整个项目中没被调用的函数
- 常量传播：跨文件传递常量值
启用LTO的方法：
# 编译和链接时都加上 -flto
gcc -c -O2 -flto file1.c
gcc -c -O2 -flto file2.c
gcc -O2 -flto file1.o file2.o -o output.elf我曾经在一个点钞机项目里，光靠打开LTO，就把固件体积缩小了15%，同时性能还提升了约8%。这效果，说实话比单纯从-O2升到-O3要明显得多。
4.4 避坑指南
我曾经踩过的坑：
- LTO + 弱符号：如果用了__attribute__((weak))，LTO可能会把弱符号优化掉，导致链接失败
- 调试信息丢失：LTO会重排代码，导致gdb调试时行号对不上
- 编译时间暴增：LTO需要做全局分析，大型项目编译时间可能翻倍
所以我的做法是：开发阶段不开LTO，只在发布固件前做一次LTO编译。这样既保证了开发效率，又享受了优化红利。
4.5 实际项目中的选择策略
说了这么多，到底怎么选？我总结了一个简单的决策流程：
- 先上-O2，这是最稳妥的选择
- 测量性能，看是否满足需求
- 如果不够，尝试对热点模块单独开-O3
- 最后开LTO，做一次全局优化
- 全面测试，确保功能正常
你想想看，点钞机每秒要处理几十张钞票，每张钞票要识别真伪、计数、判断面额。这中间任何一个小bug，都可能导致数错钱。所以优化要大胆，测试要小心。
总结一下：
-O2是点钞机项目的“甜点”优化等级。LTO是锦上添花的好工具。至于-O3，除非你很清楚自己在做什么，否则慎用。
好了，这一章就聊到这儿。下一章咱们讲讲内存对齐和缓存优化，这可是点钞机高速处理的关键。