LICM 默认不提升循环内计算的根本原因是安全性保守策略，而非能力不足；它依赖别名分析、副作用判断和异常控制流信息，在缺乏足够证据时拒绝提升以确保语义正确。
LLVM 的 LICM（Loop-Invariant Code Motion）默认不把某些计算移出循环，根本原因不是它“不会”，而是它**不敢**——在缺乏足够别名信息（alias info）或控制流确定性时，移动可能改变语义。
为什么 LICM 拒绝 hoist 一个看似不变的 load 或算术表达式
常见现象是：你写了一个循环，里面有个 load a[i] 或 a[0] + b[0]，明明没被修改，但 opt -licm 后 IR 里它仍在循环内。这不是 bug，是保守决策。
关键判断依据有三个：
-
LICM要求操作数在循环中“loop-invariant”且“safe to hoist”——后者依赖AAResultsWrapperPass提供的别名分析结果；若分析返回MayAlias（比如两个指针都来自参数int *a, *b），它就拒绝 hoist 任何涉及它们的 load/store - 即使值不变，若该 load 有潜在副作用（如指向 memory-mapped I/O 区域，或被
volatile修饰），LICM会跳过——IR 中对应load volatile或有!invariant.loadmetadata 的指令不会被提升 - 循环存在异常出口（如 C++ exception edge、invoke 指令）时，
LICM默认禁用，除非显式开启-enable-licm-with-exceptions
如何让 LICM 实际 hoist 你的计算
不是调高优化级（-O2 已含 LICM）就能解决。你需要给它可信赖的证据：
- 在源码中加
restrict（C）或__restrict（Clang），或用noaliasmetadata 标记指针参数，让前端生成更强的 alias info - 确认循环没有
invoke或unwind边；如有，加-enable-licm-with-exceptions并确保LangOptions.Exceptions已启用 - 用
opt -passes='require<aa>,licm'</aa>显式插入别名分析，避免 pass manager 自动跳过（尤其在 new PM 下） - 检查 IR 中目标指令是否有
!invariant.load：没有的话，LICM不会假设其不变；可用llvm.loop.invariant.groupmetadata 手动标注（需自定义 pass 或 clang plugin）
LoopVersioningLICM 是 LICM 的替代方案吗
不是替代，是补充。当你无法提供 noalias 保证，又想解锁 LICM 机会时，LoopVersioningLICM 才派上用场。
它不直接 hoist，而是：
- 插入 runtime check（如
a + n ）判断是否 alias-free - 分裂循环为两个版本：安全版（hoist load/store）、通用版（保留原逻辑）
- 仅当 check 为 true 时走优化路径——所以它增加分支开销，但换来了 LICM 机会
启用方式必须显式：clang -O2 -mllvm -enable-loop-versioning-licm 或 opt -loop-versioning-licm；它不在 -O2 默认 pipeline 中。
真正容易被忽略的是：LICM 的行为高度依赖 IR 层面的别名元数据和控制流完整性，而不是源码“看起来不变”。调试时先用 opt -analyze -loops -aa-eval 看别名分析结论，比盲目改源码更有效。
