编译器优化入门：GCC 优化等级详解

嵌入式开发里，编译器优化是个绕不开的话题。很多新手拿到 GCC 后，直接默认 -O0 编译，跑起来发现代码又大又慢。也有人图省事，上来就开 -O3，结果程序跑飞了都不知道为什么。

我个人习惯是：先搞清楚每个优化等级到底干了什么，再根据项目需求去选。今天咱们就把 GCC 的 -O0、-O1、-O2、-O3、-Os 这几个等级掰开揉碎讲清楚。

优化等级全景图

先看一张整体结构图，帮你建立全局认知：

-O0：无优化，调试专用

这是 GCC 的默认等级。编译器几乎不做任何优化，代码逐字逐句翻译成机器码。好处是调试体验极好——你设的断点、单步执行、变量查看，全都和源码一一对应。

但代价也很明显：代码体积最大，执行速度最慢。我见过有人把 -O0 编译的固件直接烧到量产产品里，结果 Flash 爆了，跑起来还卡顿。嗯，这其实是个坑。

-O1：基础优化，快速编译

-O1 开启了一组基础优化，比如：

• 常量折叠（Constant Folding）—— 编译时直接算出常量表达式
• 死代码消除（Dead Code Elimination）—— 删掉永远不会执行的代码
• 跳转优化（Jump Optimization）—— 简化分支跳转

这个等级编译速度很快，代码体积和性能都有改善。但我个人很少在生产中用 -O1，因为它优化的力度不够，很多该做的优化都没做。

-O2：生产环境的首选

这是我最常用的等级，也是大多数嵌入式项目的推荐选择。-O2 在 -O1 基础上增加了大量优化，包括：

• 循环展开（Loop Unrolling）—— 减少循环控制开销
• 指令调度（Instruction Scheduling）—— 重排指令减少流水线停顿
• 函数内联（Function Inlining）—— 小函数直接嵌入调用处
• 公共子表达式消除（CSE）—— 避免重复计算

我在一个 STM32 项目里做过对比：同样的代码，-O0 编译出来 128KB，-O2 只有 72KB，性能提升了将近 40%。而且 -O2 的优化相对保守，很少引入 bug。

-O3：性能至上，但需谨慎

-O3 在 -O2 基础上开启了更激进的优化，比如：

• 更积极的函数内联
• 向量化（自动使用 SIMD 指令）
• 更激进的循环变换

性能确实能再提升 10%-20%，但代价也不小。我曾经在一个 ARM Cortex-M4 项目里用 -O3，结果程序跑着跑着就挂了。查了半天，发现是编译器把一个 volatile 变量优化掉了——它觉得这个变量从来没被修改过，直接给删了。

-Os：尺寸优先，Flash 紧张时的救星

-Os 的目标很明确：尽可能减小代码体积。它基于 -O2，但关闭了那些会增大代码的优化（比如循环展开），同时开启了一些专门减体积的技巧。

我有个项目 Flash 只剩 4KB 空间，功能还要加。换成 -Os 后，代码直接小了 18%，刚好塞进去。当然，性能会有所下降，大概比 -O2 慢 5%-10%。

什么时候用 -Os？

• Flash 容量快用完了
• 对性能要求不高，但成本敏感
• Bootloader 这类体积受限的模块

各等级对比一览

下面这张表总结了关键差异：

等级	编译速度	代码大小	执行速度	调试体验	推荐场景
-O0	最快	最大	最慢	最好	开发调试
-O1	快	中等	中等	好	快速验证
-O2	中等	较小	快	一般	生产首选
-O3	慢	可能增大	最快	差	性能极致
-Os	中等	最小	较快	一般	Flash 紧张

实际项目中的选择策略

说了这么多，到底怎么选？我总结了一个简单的决策流程：

1. 开发阶段：用 -O0，方便调试
2. 功能验证后：切到 -O2，看功能和性能是否满足
3. Flash 不够：试 -Os，评估性能损失能否接受
4. 性能瓶颈：局部用 -O3 优化热点函数，而不是全局开启

另外提一句，GCC 还支持按文件甚至按函数指定优化等级。比如某个关键函数用 -O3，其他文件保持 -O2。这个技巧在大型项目中非常实用，后面章节我会详细讲。