MLIR的Cache（缓存）行为分析与优化从一次诡异的性能回退说起去年冬天调一个AI推理引擎的编译后端，模型在A100上跑得好好的，换到V100上推理延迟反而比基线高了15%。代码没改，算子没换，唯一的变化是MLIR版本从14升级到了17。当时第一反应是“MLIR又搞了什么幺蛾子”，结果profile一看，L2 cache miss率从12%飙到了38%。顺着火焰图往下挖，发现是MLIR的bufferization pass在生成中间表示时，把原本连续的内存访问模式打散成了跨步访问——这就是典型的“编译器优化反噬硬件特性”的案例。从那以后，我开始认真对待MLIR的缓存行为。今天这篇笔记，就聊聊我在MLIR缓存问题上踩过的坑，以及怎么从IR层面预判和修复这类问题。MLIR的缓存问题藏在哪MLIR本身不直接管理硬件缓存，但它生成的IR结构会直接影响LLVM后端和最终机器码的缓存局部性。问题通常出现在三个层面：第一层：MemRef的布局与访问模式。MLIR的MemRef类型支持动态维度、非连续布局（如affine_map定义的跨步），但很多pass在转换时会把一个连续张量拆成多个子视图，导致后续循环生成非连续地址流。比如memref.subview操作，如果子视图的步长不是1，LLVM的自动向量化就会失效，缓存行利用率直接腰斩。第二层：循环分块与tile size的选择。MLIR的affine dial