-O参数控制LLVM IR层优化流水线，-O0至-O3依次启用更多Pass（如内联、向量化），后端仅将优化后的IR翻译为机器码；LTO支持跨模块优化，-Og兼顾调试与性能。
clang -O 参数直接控制 IR 优化流水线
LLVM 本身不“生成不同优化级别的机器码”，真正起作用的是 clang 命令行传入的 -O 级别，它会触发对应预设的优化 Pass 序列，作用于 LLVM IR 阶段。这些 Pass 在 IR 层完成变换（如循环展开、内联、向量化），之后才进入后端代码生成。换句话说：优化发生在 IR 上，不是在汇编或机器码上“再加工”。
常见误解是以为 -O2 和 -O3 只是让后端“更努力地选指令”，其实差别主要在 IR 层是否已把循环展开了、函数是否已内联了、数组访问是否已向量化了——后端只是忠实地把优化后的 IR 翻译成目标指令。
-
-O0：几乎不运行优化 Pass，IR 几乎等价于源码结构，调试体验最好 -
-O1：启用基础流水线，如-instcombine、-simplifycfg、-loops，适合调试+轻量提速 -
-O2：加入-inline、-fvectorize、-slp-vectorize，适合绝大多数 Release 场景 -
-O3：追加-aggressive-instcombine、-callsite-splitting，可能破坏可预测性（比如过度内联导致栈溢出）
后端不重跑优化，但受 IR 形态强烈影响
LLVM 后端（如 X86ISel 或 AArch64ISel）本身不重新判断“要不要向量化”，它只做三件事：指令选择（ISel）、寄存器分配、指令调度。而这些步骤的输入，就是优化后 IR 经过 SelectionDAG 转换出的 DAG 图——如果 -O2 已经把一个循环向量化成 的向量操作，后端就自然生成 SSE/NEON 指令；如果 IR 还是标量循环，后端就只能生成普通 load/store + add。
所以你看到的“-O3 生成了 AVX 指令”，真实原因是 -O3 启用了 -fvectorize 和更激进的 -unroll-threshold，让 IR 层提前完成了向量化建模，后端只是照单翻译。
- 同一个 IR 输入，不同后端（x86 vs aarch64）生成的机器码不同，但优化级别不影响后端行为逻辑
- 后端不会因为加了
-O3就自动开启未在 IR 中体现的向量化——它没这个能力，也不该有 - 若想确认某次编译是否真做了向量化，用
clang -O2 -mllvm --print-after=loop-vectorize查看 IR 变化
链接时优化（LTO）才是真正跨模块的机器码级机会
常规 -O2 是模块级优化：每个 .c 编译成独立 .o，IR 优化只在单文件内进行。而 -flto（Link Time Optimization）让 clang 输出 bitcode（.bc）而非目标文件，等到链接阶段（lld 或 gold）才把所有 .bc 合并、重跑优化 Pass——这时才能做跨文件函数内联、全局死代码消除、甚至跨模块向量化。
注意：-flto 不等于“更高优化级别”，而是“更广优化范围”。它常和 -O2 搭配使用，而不是替代 -O3。
-
clang -O2 -flto -c a.c b.c→ 生成a.o、b.o（实际是 bitcode） -
clang -O2 -flto a.o b.o -o prog→ 链接时合并 IR 并重优化 - 不加
-flto时，即使写-O3，也无法内联b.c里的静态函数到a.c中
容易被忽略的细节：调试信息与优化的隐式冲突
很多人发现加了 -O2 后 gdb 单步跳变、变量显示为 <optimized out></optimized>，这不是 bug，而是优化改变了执行流和存储位置。LLVM 默认在 -O 及以上保留调试符号（-g），但不保证变量生命周期或行号映射完全准确。
如果你需要可观测性又不能降级优化，可行方案有限：
- 用
-O2 -g -frecord-gcc-switches保留编译参数痕迹，辅助事后分析 - 对关键函数加
__attribute__((optnone))禁用优化，但仅限小范围 - 避免依赖
stepi级别单步——它在高度优化代码里本就不稳定 -
-Og是折中选项（GCC 引入，Clang 也支持），它启用部分优化但优先保障调试体验，比-O0快，比-O2可调
最麻烦的其实是 -O3 下的跨函数寄存器重用和尾调用优化：它们会让调用栈“塌陷”，backtrace 失效，而这个问题在 IR 层已成定局，后端无从补救。
