MLIR的Bank Conflict（存储体冲突）避免从一次诡异的性能抖动说起去年在调一个AI加速器后端时，遇到一个让人抓狂的问题：同样的计算图，输入尺寸只差1个元素，性能却差了30%。反复检查指令序列、内存分配，甚至怀疑是硬件bug。最后用硬件性能计数器一查——bank conflict次数从几百飙升到几十万。那一刻，我意识到MLIR的buffer分配策略在底层bank冲突面前，就是个“天真少年”。存储体冲突的本质：不是内存，是“门”很多人把bank conflict理解成“内存访问冲突”，这其实是个误区。现代SRAM（比如GPU的shared memory、NPU的本地存储）被划分成多个独立的存储体（bank），每个bank有自己的读写端口。想象一个银行有16个柜台，每个柜台只能同时服务一个客户。如果你和另一个人同时冲向同一个柜台，就得排队——这就是bank conflict。关键点：bank conflict不是内存地址冲突，而是地址映射到同一个bank的索引冲突。比如一个16bank的SRAM，地址0和地址16都映射到bank0，因为它们对16取模的结果相同。MLIR中bank conflict的“隐形陷阱”MLIR的bufferization和memory规划层，默认是“逻辑正确优先”。它会把多维数组线性化成一维地址空间，然后按顺序分配。这在单bank场景下没问题，但一旦硬件有多个bank，这种“懒