Open j2kun opened 1 year ago
Thanks for opening this. After taking a quick look, I'm not sure exactly what part of the input MLIR causes this issue, but it seems we are trying to check a memory dependence between a pair of memory operations that the upstream MLIR memory dependence utility asserts we should not be checking. We can probably adjust which memory dependences we check to avoid this issue.
Another point to bring up: this example is hitting this issue because it contains nested Affine loops. While the memory dependence analysis should support nested loops (and we should do something like what I mentioned above), the -convert-affine-to-pipeline pass does not. We have open issues on this topic for some time, and there is some interest in figuring out a way to make it work. This may or may not be the point in the design space you are interested in, but if you want to get something to work today, you can unroll the inner loops in each nest until there is just one Affine loop for each original loop nest.
I'd like to convert some scf/affine MLIR to verilog, and while I am sure there are multiple problems with my input MLIR (I'm figuring out which additional passes I need to run to get it into a suitable form), I'm running into some
mlir-opt
crashes and thought it might be worthwhile to submit them as bug reports.I'm struggling a bit to minimize the example to a small reproduction, in part because I don't understand what section of the input
mlir-opt
is unable to handle. I would appreciate some advice on what part to extract to make this bug simpler to triage.repro.mlir.txt
Command (named
txt
so GitHub would let me attach it to this issue):Error logs: