memoryssa专用于分析单函数内内存操作的支配与覆盖关系，不解决指针别名问题；其核心是快速定位支配的最近内存定义或被覆盖的后续访问，支撑循环优化等场景。
MemorySSA适合分析内存操作间的支配与覆盖关系
它不是通用别名分析工具，也不回答“两个指针是否可能指向同一地址”这种问题；它的核心能力是：给定一条StoreInst或LoadInst，快速找出在控制流上“支配它”的最近内存定义（def），或“被它覆盖”的后续内存访问（clobber）。这直接支撑了诸如循环优化、内存提升（hoisting）、冗余store消除等场景。
-
getClobberingMemoryAccess()返回的是支配路径上最后一个能修改该内存位置的MemoryAccess，不是任意可能冲突的访问 - 它只工作在单个函数内（
intra-procedure），跨函数调用必须靠CallInst的ModRef信息配合别名分析（如AAResultsWrapperPass）补全 - 对
alloca分配的栈内存效果最好；对全局变量或堆内存，结果依赖底层别名分析（BAA）的质量，容易因保守估计而返回nullptr或过度近似
不适用于直接判断指针别名或数据竞争
如果你在写一个检测data race的Pass，别指望MemorySSA返回MustAlias或NoAlias——它根本不做这个。它的MemoryLocation参数虽然包含Ptr和Size，但查询时只用来喂给底层BatchAAResults做一次alias判定，最终仍退化为MayAlias主导的结果。
- 常见误用：传入两个不同
GetElementPtrInst的Ptr，期望getClobberingMemoryAccess能区分它们是否重叠 → 实际返回的往往是同一个MemoryDef，因为别名分析无法精确建模偏移 -
MemorySSA构建时不验证指针有效性，Loc.Ptr == nullptr会直接返回StartingAccess，容易掩盖空指针解引用类错误 - 它不跟踪
volatile或atomic标记，所有访问一律按普通内存处理；对__atomic_store这类指令，需额外识别并跳过
配合PHINode做跨基本块内存版本推导时要小心
MemorySSA本身不生成PHINode，但它维护的MemoryPhi节点（继承自MemoryAccess）用于合并来自不同前驱块的内存版本。当你遍历MemoryPhi的incoming值时，拿到的是其他MemoryAccess指针，不是IR指令——不能直接cast成StoreInst或LoadInst。
- 正确做法：先用
dyn_cast<memoryuseordef></memoryuseordef>确认类型，再调用getMemoryInst()获取对应IR指令 -
MemoryPhi的getNumIncomingValues()返回的是支配边界数，不是实际活跃路径数；某些入口可能已被unreachable块污染，需结合DominatorTree过滤 - 对含
invoke的异常路径，MemorySSA默认不建模EH edge，除非显式启用-enable-mssa-eh（LLVM 17+）
构建开销低，但查询结果依赖前期Pass顺序
MemorySSA的构建复杂度接近O(N)，比MemoryDependenceAnalysis快一个数量级，但它要求前置的LoopInfo、DominatorTree、AAResultsWrapperPass已就绪。如果在runOnFunction里手动触发getAnalysis<...>()</...>失败，大概率是PassManager没按依赖顺序注册。
- 典型依赖链：
DominatorTreeWrapperPass→LoopInfoWrapperPass→AAResultsWrapperPass→MemorySSAWrapperPass - LLVM 16起默认禁用
MemorySSA，必须在CMakeLists.txt中加add_llvm_pass(YourPass DEPENDS MemorySSA)，否则getAnalysis<memoryssawrapperpass></memoryssawrapperpass>会崩溃 - 调试时可用
print方法输出整个MemorySSA结构：MSSA->print(dbgs())，但注意它不显示MemoryLocation细节，得自己dump每个MemoryAccess的getMemoryInst()
getClobberingMemoryAccess，而是理解它返回的那个MemoryAccess到底代表哪条指令、在什么条件下有效、以及当它返回nullptr时你该信还是不该信。
