module pass 可通过 getanalysis() 获取 function pass 分析结果，但需在 getanalysisusage 中显式声明 addrequired() 依赖；function pass 不可反向依赖 module pass，因 legacy pm 禁止该行为。
Module Pass 怎么拿到 Function Pass 的分析结果
Module Pass 可以安全请求 Function Pass 的分析结果，前提是该 Function Pass 已在 Module Pass 执行前注册并运行过。关键在于 getAnalysis<t>()</t> 接口的调用时机和依赖声明。
常见错误现象：在 runOnModule() 里直接调用 getAnalysis<myfunctionanalysis>()</myfunctionanalysis> 却报错 “Pass not found” 或断言失败 —— 这通常是因为没在 getAnalysisUsage(AU) 中显式声明依赖。
- 必须重写
getAnalysisUsage(AU)，并在其中调用AU.addRequired<myfunctionanalysis>()</myfunctionanalysis> - Legacy PM 要求 Function Pass 必须是
FunctionPass子类（不能是AnalysisPass<function></function>新式写法），否则getAnalysis查不到 - Module Pass 拿到的是每个函数各自的分析实例，需遍历
M.getFunctionList()后对每个Function*调用&getAnalysis<myfunctionanalysis>(*F)</myfunctionanalysis> - 性能影响：若 Function Pass 是
ImmutablePass（如TargetLibraryInfoWrapperPass），结果可跨函数复用；否则每次调用都返回对应函数的独立结果
Function Pass 能不能反向依赖 Module Pass
不能。Legacy Pass Manager 明确禁止 Function Pass 请求 Module Pass 的分析结果，因为执行顺序上 Module Pass 在整个模块上只跑一次，而 Function Pass 对每个函数单独执行，无法保证 Module Pass 已就绪或其结果仍有效。
典型错误现象：getAnalysis<mymoduleanalysis>()</mymoduleanalysis> 在 runOnFunction() 中触发断言或空指针解引用 —— LLVM 会直接拒绝注册这种依赖关系。
- 替代方案：把需要全局信息的部分拆成
ImmutablePass（如自定义的GlobalSymbolTablePass），它不随函数变化，可在 Function Pass 中用getAnalysis<t>()</t>安全获取 - 或者改用新 Pass Manager（
PassBuilder+AnalysisManager<module></module>），它支持跨层级依赖，但需重构整个 Pass 注册与使用逻辑 - 硬编码绕过（不推荐）：在 Function Pass 构造时传入 Module 引用并手动缓存所需数据，但这破坏了 Pass 的可组合性和生命周期管理
为什么 BasicAliasAnalysis 能被所有层级 Pass 使用
因为它被设计为 ImmutablePass，且注册在全局 Analysis Resolver 中，不绑定具体 IR 单元生命周期。任何 Pass（Module/Function/Loop）只要声明依赖，就能通过 getAnalysis<aliasanalysis>()</aliasanalysis> 获取统一接口。
容易踩的坑是误以为所有别名分析 Pass 都能跨层级用 —— 实际上只有继承自 ImmutablePass 并正确注册到 AnalysisGroup 的才支持。比如 BasicAAResultsWrapperPass 是 Function 级 wrapper，而底层 BasicAliasAnalysis 本身才是 Immutable。
- 检查方式：看源码中是否继承
ImmutablePass，以及是否调用RegisterAnalysisGroup<aliasanalysis></aliasanalysis> - 自定义时若想复现类似行为，必须同时满足：不修改 IR、不依赖函数局部状态、注册为
ImmutablePass、加入对应AnalysisGroup - 注意兼容性：LLVM 14+ 默认启用新 Pass Manager，
ImmutablePass语义略有变化，旧代码在新 PM 下可能被忽略或报 warning
新旧 Pass Manager 在跨层级传递上的根本差异
Legacy PM 用“执行顺序+显式依赖声明”硬约束层级关系；新 PM（PassBuilder）用 AnalysisManager<irunit></irunit> 按需缓存和传播，允许 Module 分析结果自动向下注入到 Function Pass 中，无需手动 addRequired。
这意味着你在新 PM 下写一个 ModuleAnalysis，然后在 FunctionPass 的 run() 函数里直接用 AM.getResult<mymoduleanalysis>(M)</mymoduleanalysis> 就行 —— 不报错、不声明、不管理生命周期。
- 但代价是：你得放弃
opt -load插件方式，改用PassBuilder::registerPipelineStartEPCallback注入 pipeline - 构建系统也要切到 CMake 的
add_llvm_pass_plugin，而非旧式add_llvm_library+PLUGIN_TOOL - 最易忽略的一点：新 PM 默认不运行 Legacy Pass，混用会导致部分分析缺失，尤其在调试时难以定位是哪个 Pass 没生效
