llvm ir层pass执行顺序直接影响数据流分析输入状态：mem2reg等前置pass改变cfg和支配关系，使后续pass如deadcodeelim能识别冗余指令；顺序颠倒则导致优化失效、编译变慢或ir非法。
IR 层 Pass 的执行顺序直接影响数据流分析的输入状态
LLVM IR 是 SSA 形式，但每个 Pass 对 IR 的修改会改变后续 Pass 看到的控制流图（CFG）、支配关系、活跃变量集合等基础信息。比如 mem2reg 把内存访问提升为寄存器操作后，deadcodeelim 才能识别出原本被内存别名遮蔽的无用指令；如果顺序颠倒，deadcodeelim 会因无法证明指针不逃逸而保守保留代码。
常见错误现象：opt -passes='dce,mem2reg' input.ll 输出中仍有大量未提升的 %ptr = alloca 指令，且后续循环优化失效——因为 dce 在 mem2reg 前运行，根本看不到可被消除的冗余 load/store 链。
- 必须前置的典型 Pass：
mem2reg、instnamer、globaldce（清理全局符号依赖） - 依赖 SSA 成熟度的 Pass：
loop-rotate要求循环已规范化，licm要求循环有明确的入口块 - 性能影响：顺序错乱可能导致某 Pass 反复触发（如
simplifycfg在loop-unroll后生成新分支，又被jump-threading重处理），编译时间翻倍
后端机器码 Pass 的顺序受寄存器压力和指令延迟约束
IR 层优化不感知硬件细节，但后端 Pass（如 register-allocator、machine-scheduler）必须按微架构特性严格排序。例如在 ARM Cortex-A53 上，register-allocator 必须在 machine-scheduler 之前运行——否则调度器按理想寄存器数量排布指令，分配器发现寄存器不足时只能插入 spill/reload，破坏流水线连续性。
使用场景：你手动加了 -passes='loop-unroll,regalloc,schedule'，结果生成代码比不加 loop-unroll 还慢 20%，就是因为 regalloc 在 schedule 前强制溢出，而 schedule 本可利用指令级并行隐藏访存延迟。
- 关键依赖链：
isel→peephole→regalloc→schedule→branch-folder - ARM/AArch64 后端中，
regalloc默认使用greedy算法，若在schedule后运行，会因指令位置固定而丧失重排空间 - 错误配置示例：
opt -passes='regalloc,schedule' -mtriple=armv7a-none-eabi会直接报错Cannot schedule before register allocation
Pass 间隐式依赖常被 opt 命令行忽略
opt 工具支持显式指定 Pass 序列，但它不会自动注入缺失的前置 Pass。比如你只写 -passes='loop-vectorize'，LLVM 不会自动补上 loop-simplify 和 loop-rotate——而这两个是 loop-vectorize 的硬性前提，缺失会导致断言失败或静默跳过优化。
参数差异：-O2 内置管线会自动展开完整依赖链（含 loop-simplify → loop-rotate → loop-vectorize），但手写 -passes 时必须显式列出全部依赖。
- 安全写法：
opt -passes='loop-simplify,loop-rotate,loop-vectorize' input.ll - 检查依赖：用
opt -debug-pass=Structure -passes='loop-vectorize' /dev/null 2>&1 | grep -A5 'Required'查看实际依赖 - 容易踩的坑：某些 Pass（如
coro-split）要求函数已做function-attrs分析，漏掉会导致协程状态机生成错误
自定义 Pass 插入点选错会导致 IR 非法
LLVM Pass 分为 FunctionPass、LoopPass、MachineFunctionPass 等类型，每种有严格的执行上下文。把一个期望操作 MachineInstr 的 Pass 插入 IR 层管线（如放在 mem2reg 后），会因 IR 尚未降级而触发 Assertion failed: isa<instruction>(MI)</instruction> 错误。
真实调试场景：你开发了一个针对 ARM NEON 指令的向量化 Pass，测试时在 opt -passes='mynativevec' 下崩溃，堆栈指向 MachineInstr::getOpcode() ——说明它被错误地当成了 IR Pass 加载，实际应注册为 MachineFunctionPass 并插入后端管线。
- 判断依据：看 Pass 处理的对象类型——如果是
Instruction*或BasicBlock*，属于 IR 层；若是MachineInstr*或MachineBasicBlock*，必须走机器码层 - 注册位置决定执行时机：
addPass()在TargetPassConfig::addMachinePasses()中才有效 - 最隐蔽的问题：某些 Pass（如
early-cse）在 IR 和机器码层同名但实现不同，调用错版本会导致优化语义错乱
PassManager.h 和目标后端的 XXXTargetMachine.cpp。顺序错一次，可能只是性能回退；错两次，IR 可能进入未定义状态，后续所有优化都不可信。
