Checklists for adding dialects / transformations

[AntonLydike]

I want to collect a bunch of things you should take care of when implementing a dialect / or a transformation. Ideally we also add some links to examples for each step?

Adding a dialect

• Put your dialect into xsl/dialects
• One dialect per file
• You might want to have one abstract "base operation" all your dialects subclass from if you have some common state, or want to easily identify your operations in e.g. RewritePatterns
• Make sure your dialect follows the naming scheme of <Opname>Op for operations and <name>Type for types.
• Types should probably inherit from MLIRType
• After you are done, make sure to define your dialect using Dialect([list of ops], [list of attributes])
• Make sure to add your dialect to the XdslOptMain.register_all_dialects method

Adding a transformation

• Put your transformation in xdsl/transformations
• Have one PatternRewriter per rewrite-kind you have (e.g. one optimization, or a lowering for a single op)
• Try to have one "optimization/rewrite pass" per file
• Define a function that applies the rewrite, like this TODO: link to place in main branch once merged
• Register your pass with the XdslOptMain.register_all_passes method

[webmiche]

I guess we might want to distinguish between in-tree and out-of-tree dialects/transforms as our framework is flexible enough to handle both.

For the transformations, I think you have mistaken PatternRewriter for RewritePatterns, right?. Usually, I use one pattern per operation when lowering. When optimizing, I try to apply on as small units as possible to have peephole rewrites. If you don't have state, you can also use anonymous rewrites (just a function), though I advise against it as they are not as flexible (say you need to add state in the future) and less intuitive to me personally.

Also, the Walker can be parametrized to walk in several ways (regions-first, reverse block order, or recursive application).

In the future, we probably want smarter PatternAppliers, but maybe we add docu to those, when they are actually implemented 😅

These are the main thoughts from the top of my head.

[PapyChacal]

Nice thing to have, thanks!
Just giving my feedback on dialect as I don't have as 'uch experience with rewrites:

• You might want to have one abstract "base operation" all your dialects subclass from if you have some common state, or want to easily identify your operations in e.g. RewritePatterns

I think this point may be too dialect-specific to put in general dialect guidelines? I'm not sure
Maybe in some FAQ or something
Similarly, The GPU dialect use a specific GPU Module to group operations in some contexts and guard/enable optimisations inside.

• Make sure your dialect follows the naming scheme of <Opname>Op for operations and <name>Type for types.

There is <name>Attr too, for non-type attributes

• Types should probably inherit from MLIRType

Is this true in general, or only for existing MLIR types?

I have a feeling that many of our guidelines may slightly differ for MLIR dialects implementations in xDSL, and xDSL dialects "from scratch" (had similar thoughts on testing)

• After you are done, make sure to define your dialect using Dialect([list of ops], [list of attributes])
• Make sure to add your dialect to the XdslOptMain.register_all_dialects method

I would rephrase this, as it is often done during development to iterate? E.g. adding it to register_all_dialects was amongst my first steps.

[webmiche]

Is this true in general, or only for existing MLIR types?

AFAIK, this mainly changes the print for the MLIR syntax, from prefix # to !. I don't think it has other properties really.

[PapyChacal]

Oh, because MLIR makes the distinction between !type and #attr, right?

[webmiche]

Exactly :)