-o0生成的llvm ir是源码直译的调试友好型表示，保留原始结构；-o2则经多轮优化pass重构，将变量提升为ssa、展开循环、消除冗余指令。
因为 -O0 和 -O2 生成的 LLVM IR 根本不是同一类中间表示：前者是“源码快照”，后者是“语义等价但结构重写”的优化结果。 这不是编译器“偷懒”或“出错”，而是优化策略在 IR 层就已分道扬镳。
LLVM IR 在 -O0 下只是源码的直译
-O0 的目标是调试友好，所以 Clang 前端生成 IR 时几乎不做变换：
-
volatile变量、循环边界、函数调用都被原样保留为显式内存访问和控制流指令 - 每个 C 语句基本对应一个或几个 IR 指令（如
%1 = load i32, ptr %flag），不合并、不重排、不内联 - IR 中大量使用未优化的 phi 节点和冗余 store/load 对，SSA 形式存在但未被利用
- 你用
clang -O0 -S -emit-llvm main.c看到的.ll文件，基本能和 C 行号对上
-O2 的 IR 是经过多轮 Pass 改写的产物
-O2 启动了全套优化管线（opt 工具链里的数十个 Pass），IR 在进入后端前已被深度重构：
-
mem2reg把局部变量提升为 SSA 寄存器（%x = alloca i32→ 直接用%x1 = add i32 %a, %b） -
loop-unroll展开循环，IR 中出现重复块和跳转标签（for (i=0; i → 四组独立 <code>store） -
instcombine合并常量运算（%t = add i32 %a, 5; %u = mul i32 %t, 2→ 直接%u = mul i32 %a, 2加常量偏移） -
gvn（Global Value Numbering）消除冗余 load，比如对同一volatile地址连续读两次，在 -O2 IR 中可能只剩一次 —— 这正是中断标志失效的根源
为什么看 IR 就能定位 -O2 崩溃？
很多嵌入式问题在汇编层才暴露，但 IR 层更早、更干净地揭示了编译器“怎么想的”：
- 如果
volatile变量在 -O2 IR 中被load消除或缓存在寄存器里（即没出现在循环体内），说明它已违反语义约束 - 函数内联后，原本独立的 ISR 上下文和主循环逻辑在 IR 中混成一块，容易看出竞态点
- 用
opt -print-after-all可以逐 Pass 观察 IR 变化，比反汇编更直接——例如看到loop-vectorize插入了非对齐访问，就解释了 ESP32-C3 上的 hardfault - 对比
clang -O0 -emit-llvm和clang -O2 -emit-llvm输出，差异集中在loop、load、call三类指令的密度与模式上
真正难的不是看懂 IR 差异，而是意识到：IR 不是“中间过程”，它是编译器对你代码意图的正式声明。-O2 下的 IR 已默认你遵守了 C 标准所有隐含契约——一旦你漏写了 volatile、用了未初始化指针、依赖求值顺序，IR 就会坦率地删掉那些“编译器认为不可能发生”的分支。这一步，比任何运行时崩溃都更早亮起红灯。
