MLIR的Dataflow（数据流）模型与静态调度
从一次诡异的死锁说起
去年调一个AI加速器后端，跑一个简单的卷积+ReLU+池化流水线，结果在硬件仿真阶段卡死了。波形一看，某个PE（处理单元）的输入缓冲一直空着，但上游的DMA明明已经把数据写到了共享内存。查了三天，最后发现是MLIR生成的调度顺序出了问题——池化层的数据依赖没被正确识别，导致DMA和PE之间产生了循环等待。
这个坑让我意识到，MLIR的Dataflow模型不是“自动帮你搞定一切”的黑盒。它更像一个精密的时钟机构，每个齿轮的咬合顺序，决定了整个系统能不能转起来。
Dataflow的本质：谁说顺序执行才是王道？
传统编译器里，我们习惯用控制流图（CFG）来思考：if-else分支、循环跳转、函数调用。但硬件加速器、FPGA、甚至多核DSP，它们更关心的是“数据什么时候准备好”，而不是“指令执行到哪一行”。
MLIR的Dataflow模型，核心就一句话：操作（Operation）的执行，由它的操作数（Operand）是否就绪决定。听起来像数据流计算机？没错，MLIR把这种思想带到了中间表示层。
看一个最简单的例子：
%0 = arith.addi %a, %b : i32 %1 = arith.muli %0, %c : i32在传统调度里，编译器会保证%0先算，再算
