search

tenstorrent / tt-mlir

Tenstorrent MLIR compiler
https://tenstorrent.github.io/tt-mlir/
Apache License 2.0
76 stars 13 forks source link

Fix unregistered dialects error message (ttmlir-translate) #1341

Closed svuckovicTT closed 1 day ago

svuckovicTT commented 2 days ago

Running:

./build/bin/ttmlir-opt --ttir-to-ttnn-backend-pipeline="system-desc-path=ttrt-artifacts/system_desc.ttsys" --convert-ttnn-to-emitc test/ttmlir/Silicon/TTNN/emitc/simple_add.mlir > binary.mlir
./build/bin/ttmlir-translate --mlir-to-cpp binary.mlir

Produces an error:

binary.mlir:1:15: error: #"tt"<"device<workerGrid = #tt.grid<8x8, (d0, d1) -> (0, d0, d1)>, l1Map = (d0, d1)[s0, s1] -> (0, d0 floordiv s0, d1 floordiv s1, (d0 mod s0) * s1 + d1 mod s1), dramMap = (d0, d1)[s0, s1] -> (0, 0, ((((d0 floordiv s0) * 8 + d1 floordiv s1) * (s1 * s0) + (d0 mod s0) * s1 + d1 mod s1) floordiv 8192) mod 12, (((d0 floordiv s0) * 8 + d1 floordiv s1) * (s1 * s0) + (d0 mod s0) * s1 + d1 mod s1) floordiv 98304 + (((d0 floordiv s0) * 8 + d1 floordiv s1) * (s1 * s0) + (d0 mod s0) * s1 + d1 mod s1) mod 8192), meshShape = , chipIds = [0]>"> : 'none' attribute created with unregistered dialect. If this is intended, please call allowUnregisteredDialects() on the MLIRContext, or use -allow-unregistered-dialect with the MLIR opt tool used
#device = #tt.device<workerGrid = #tt.grid<8x8, (d0, d1) -> (0, d0, d1)>, l1Map = (d0, d1)[s0, s1] -> (0, d0 floordiv s0, d1 floordiv s1, (d0 mod s0) * s1 + d1 mod s1), dramMap = (d0, d1)[s0, s1] -> (0, 0, ((((d0 floordiv s0) * 8 + d1 floordiv s1) * (s1 * s0) + (d0 mod s0) * s1 + d1 mod s1) floordiv 8192) mod 12, (((d0 floordiv s0) * 8 + d1 floordiv s1) * (s1 * s0) + (d0 mod s0) * s1 + d1 mod s1) floordiv 98304 + (((d0 floordiv s0) * 8 + d1 floordiv s1) * (s1 * s0) + (d0 mod s0) * s1 + d1 mod s1) mod 8192), meshShape = , chipIds = [0]>
              ^

In order to avoid it, one must use the --allow-unregistered-dialect flag when running ttmlir-translate. The proper fix is to remove problematic attributes from the top-level ModuleOp so that the additional flag doesn't need to be used.

Updated the docs/comments as well.

nsmithtt commented 2 days ago

Interesting. Yeah I'm not sure where we can store the System Desc and device in a more "official" place, the module really feels like the best place to store it, but it feels kinda nasty to have to remove the attributes to run certain passes.

svuckovicTT commented 1 day ago

Interesting. Yeah I'm not sure where we can store the System Desc and device in a more "official" place, the module really feels like the best place to store it, but it feels kinda nasty to have to remove the attributes to run certain passes.

Yeah, I agree on both points. There might a better way to do it, but I just don't know how.

If you get any ideas on how to do it, lmk and I'll give it a shot!