Hey, @River707, I was wondering if you had more thoughts on where to go with the PDL dialect and interpreter? I’m asking because I think that something in this direction may be a good candidate for handling various op conversations in npcomp. There we have something like thousands of ops and gradients to support, some of them “hard” but most of them simple expansions of one form or another – plus the op set is open, and it would be great to not be locked to what was compiled in the binary (both for binary size/build time reasons and extensibility).
I think it’d be interesting to create some form of DSL for these cases, aimed at simplifying and standardizing these kind of high level ML op conversions. I think that the ops we are looking at would benefit from such a limited domain approach, and we could always kick out to “real” patterns for the hard cases.
I was wondering if there were any thoughts or plans in this direction, or if there was any updates on when PDL might be complete enough for real use?
I’ve been meaning to share more, but have been waiting for more of the initial pieces to land. My current plan for PDL is to get the foundation built out enough to cover many of the initial/interesting use cases. After https://reviews.llvm.org/D89107 (which adds bytecode support and the necessary end to end plumbing), PDL will “officially” be supported as a mechanism with which to write rewrite patterns in MLIR. From there, the plan is to add missing features to support variadic constructs and regions along with a general clean up of the current op definitions (as needed). The PDL layer still needs a bit of design work, but is nearly to the point where it is usable enough to start thinking about the user facing layer on top of it (given that PDL itself isn’t intended to be user facing but instead a common target for DSL-style pattern languages).
Above is the PDL aspect of it, for the pattern language that users will write, the idea right now(at least in my mind) is to move away from tablegen as the main specification language. I’ve largely been considering writing a python based pattern language that leverages the python bindings that have been under construction. IMO python would grant us much more flexibility when writing patterns than tablegen will, especially in the context of regions. At this point I don’t know what exactly this language would look like, but it is the direction that I have been gravitating towards.
This is exactly what I had in mind, at least in principle – I’ve had some rough idea about what a DSL for it could look like but nothing super concrete. There are still some things that the python bindings need to make this really work, and finishing those in the context of PDL being one of the first dialects to build gives a concrete target for some of that.
This is exciting – this could add up to a really nice feature if we do it right. I’m definitely interested in helping.
I would love to collaborate on any part of this stack, but especially on the front end DSL as this is one of the areas that I am least familiar with/thought less about so far. For the front end I only really have two main goals that I would want to achieve:
Easy to use/extend for writing patterns that cover all MLIR representations (though TBF this is kind of the goal for all pattern DSLs)
Matching full regions should be as easy as matching a DAG within a single block
Can be used at runtime to generate patterns, i.e. we are not limited to build-time only steps.
Cool - we’re aligned on those goals. I think the next step for me is to get the Python builder and dialect ops implemented so that we have something to build on top of. There are some design choices there, and it will probably take ~weeks.
Hey @River707, I think we might be at the point in the next ~week or so with the Python API to begin playing with this. When thinking through what a DSL for this looks like, it would be really helpful to have some examples to stare at. Have you worked up anything like that? Also, is this in a state that we could wire it up and use it?