mem2reg仅提升满足严格条件的alloca：未被取址、非volatile、有实际load使用、生命周期内支配关系清晰、不涉及数组/大结构体/调试信息干扰，且限于单函数内分析。
LLVM 的 mem2reg 并不是“应该消除所有局部变量”，而是只对满足严格条件的 alloca 指令做提升。它不处理的变量，往往根本不符合 SSA 构建的前提。
哪些 alloca 会被 mem2reg 忽略
即使你在 C 源码里写了一个普通 int 局部变量，Clang 生成的 IR 中对应的 alloca 也可能被 mem2reg 跳过。常见原因包括：
-
alloca被取地址（比如用了&a），导致后续出现load/store之外的指针操作，mem2reg直接放弃——它只处理“纯标量访问” - 变量被声明为
volatile，哪怕只是加了volatile int a;，mem2reg就不会碰它 -
alloca的 lifetime 跨越多个基本块，但某处store和load之间存在控制流不可达路径，或有异常分发（landing pad）干扰支配关系 - 该
alloca实际上没被任何load使用（比如只store但没读），mem2reg会先删掉整个alloca+store，而不是提升
为什么 phi 节点没出现，却仍有 load/store
看到 IR 里还有 load 和 store，不代表 mem2reg 失败了；更可能是它压根没尝试处理那个变量。检查方法很简单：
- 用
clang -S -emit-llvm -O0生成未优化 IR，确认对应变量确实是单个alloca开头、只有store/load访问 - 加上
-mllvm -debug-pass=Structure或用opt -mem2reg -S单独跑一遍，看日志里有没有Promoting alloca %a这类输出 - 如果日志里完全没提这个变量名，说明它在 pass 入口就被筛掉了——大概率是被取址或类型不匹配（例如 alloca 分配的是 struct，但代码里用了 bitcast 指针）
mem2reg 不是万能寄存器分配器
它只解决“内存到 SSA 值”的映射问题，不负责寄存器物理分配，也不处理：
- 数组（
int a[10]）：即使没取址，mem2reg也不会提升，因为无法用单个phi表达整个数组的控制流合并 - 大结构体（struct 超过几个字段）：Clang 可能直接生成 memcpy/memset 调用，绕过纯 load/store 模式
- 调试信息需要保留变量位置：启用
-g时，Clang 可能插入llvm.dbg.declare，这本身就会让mem2reg保守跳过
真正容易被忽略的一点是：mem2reg 是一个函数粒度的 pass，它不跨函数分析。如果你在一个函数里调用了另一个函数，而那个函数的参数或局部变量被间接引用（比如通过函数指针传入并修改），当前函数里的 alloca 就可能因“逃逸分析不确定”而被拒绝提升——哪怕你肉眼看不出任何问题。
