MLIR的Scratchpad Memory（暂存器）管理一个让我熬夜三天的bug去年调一个AI加速器后端，跑一个轻量级Transformer模型，死活卡在某个卷积层。硬件仿真波形显示，数据从全局内存搬运到计算单元时，中间有个暂存区（Scratchpad）的数据总是被莫名其妙地覆盖。我盯着MLIR生成的LLVM IR看了整整两天，最后发现是Scratchpad的分配策略出了问题——两个不同的算子被分配到了同一块暂存区，而它们之间并没有显式的依赖关系。这种问题在传统编译器里很少见，因为传统编译器的内存分配是“全局统一”的。但在MLIR这种多级IR的框架下，Scratchpad的管理变得极其微妙——它介于寄存器分配和全局内存分配之间，既要有寄存器的低延迟特性，又要像全局内存一样支持随机访问。搞不好，就是性能灾难。Scratchpad到底是什么先别急着看MLIR的API。Scratchpad这个概念，在嵌入式领域叫“紧耦合内存”（TCM），在GPU领域叫“共享内存”（Shared Memory），在DSP里叫“本地存储”（Local Store）。本质上，它是一块片上SRAM，访问延迟比全局DRAM低一个数量级，但容量有限（通常几十KB到几MB）。在MLIR的语境下，Scratchpad不是IR里显式定义的东西，而是内存层次结构中的一个抽象层。它出现在Dialect转换的过程中，比如从Linalg（线性代数方言）转换到GPU方言时，你会看到类似gpu.sh