I have recently been experimenting with xDSL and while it’s been very productive I have been left wondering what the current state and direction for interfacing between it and MLIR is (or more generally between any other potential high-level compiler framework and MLIR).
As far as I can tell, IRDL was at least partly intended as a bridge between xDSL and MLIR. However, while xDSL Python code can be generated from IRDL, for MLIR only the other direction is available (at least without loading IRDL at runtime), i.e. tablegen → IRDL. This means that potentially, I could define a dialect in tablegen and transform that into IRDL and then further to xDSL Python code automatically. However, there is also the possibility of going from tablegen to xDSL Python code automatically via the xdsl-tblgen program provided by xDSL. This seems to be better in some way because xDSL does not work with newer versions of the IRDL dialect while tblgen-to-irdl only handles a sufficient set of tablegen features in newer versions of llvm.
Unfortunately, I could get neither of these to fully work even for the simple cmath dialect example that both xDSL and MLIR seem to use to test these transformations. Mostly because parametrized types are not really converted from tablegen to either IRDL or Python.
Now, my questions are:
What is the current status of work on these transformations, are they being maintained in their current (experimental?) state or are there plans to make them feature complete? Especially tblgen-to-irdl
Why is there a tablegen → irdl transformation tool but none for the other direction? Could one be created or would that not make sense?
What would an ideal setup for interfacing between MLIR and xDSL or a number of other tools look like? In my mind, it seems like defining all dialects in IRDL and then generating tablegen/C++/Python/… solely from that seems like a logical next step but the absence of an irdl-to-tblgen tool makes me think that is not the intended end goal.
We’re actively working on this area, both in xDSL and in MLIR. We aim to make xDSL a productive environment in which to prototype MLIR dialects and transformations, and being able to reuse dialect definitions is a goal of ours. The current best approach is unfortunately to reimplement the dialect, which shouldn’t take very long, but we are working on automating that step out.
What is the current status of work on these transformations, are they being maintained in their current (experimental?) state or are there plans to make them feature complete? Especially tblgen-to-irdl
Why is there a tablegen → irdl transformation tool but none for the other direction? Could one be created or would that not make sense?
We implemented the features we needed at the time, but if there are some missing features that would make it more useful for your use-case, these can be added. Our group recently opened a pull request for a complementary flow, not from irdl to tablegen, but directly to C++.
What would an ideal setup for interfacing between MLIR and xDSL or a number of other tools look like? In my mind, it seems like defining all dialects in IRDL and then generating tablegen/C++/Python/… solely from that seems like a logical next step but the absence of an irdl-to-tblgen tool makes me think that is not the intended end goal.
The end goal is to make it as easy as possible to go between the two frameworks, hopefully either by automating the process, or allowing xDSL to process MLIR definitions directly with no translation needed. We’re not there yet, but we’re making a lot of progress on the Python side. If you’re interested, feel free to join the discussion on our Zulip.
Just to add to that, I think defining dialects in IRDL and using conversion to C++ and Python from that shared IRDL definition is the intended solution for maximum portability. The problem of course being that IRDL is somewhat limited in what it can define (because it is harder to have a portable spec for everything). But IRDL is meant to be expanded upon, notably to add richer attribute constraints, and also custom parsing/printing.