Dialects

[rahulmutt]

What are plans for adding some of the simpler dialects from MLIR like scf, cf, arith and adding lowering passes to the llvm dialect?

I'd be personally interesting in working on porting those over to pliron, but a couple of questions:

• where do we want new dialects to live? should they live in-tree or in separate crates and hosted in git repos as part of a larger pliron org?
• do we want to make changes to how MLIR is handling its existing dialects or should we port functionality as closely as possible?

Depending on the interest in discussion here, I can create a separate issue per dialect and we can iron out the details like scope, etc. Otherwise, I can just create my own repos and host them there.

[vaivaswatha]

where do we want new dialects to live? should they live in-tree or in separate crates and hosted in git repos as part of a larger pliron org?

I want the pliron repo (this one) to only contain the current builtin, llvm and a (near) future cranelift dialect (in addition to the core infrastructure of course). Everything else should be in different git repos.

Now, where that git repo is to be hosted is something to discuss. I hadn't considered a pliron org, so I just assumed that whoever creates one would host it on their account. The important (useful / well maintained) ones would have a link from pliron in the README (something like "related crates"). Having a pliron org wouldn't be a bad idea though.

do we want to make changes to how MLIR is handling its existing dialects or should we port functionality as closely as possible?

This should probably be decided on a case-by-case basis. Some of the dialects there are an organisational mess, but some are very well defined and formed. So it's hard to say specifically right now.

What are plans for adding some of the simpler dialects from MLIR like scf, cf, arith and adding lowering passes to the llvm dialect?

I'm working on adding a tensor (and related operations) dialect here. It's still nascent. My plan is to have tensor, memref and cf dialects there. These however probably won't be exactly matching MLIR's counterparts. For example, the tensor dialect would be a combination of MLIR's tensor and TOSA dialects. I'm planning to use burn as a frontend to get drive this (at least initially).

[vaivaswatha]

Come to think of it, cf and arith and other such general purpose dialects can stay in a separate repo themselves, not mixed with tensor etc. But since I needed cf for what I was attempting, I just added it there.

[rahulmutt]

I'd be interested in the tensor dialect as well and even linalg (not sure if you're going to merge some of the ops there). The DSL I'm implementing mostly will compile down to vectorized array ops. I know it's a bit of work, but if you can push the cf dialect to a separate repo, we can collaborate on it. Otherwise, I'd be implementing my own cf as well and we'd probably be duplicating work.

[vaivaswatha]

even linalg (not sure if you're going to merge some of the ops there).

I don't have a concrete plan yet. I just want to get something basic working end-to-end, and then I'll add more things. So I'm pretty flexible.

but if you can push the cf dialect to a separate repo, we can collaborate on it

If the tensor dialect also is going to be of use to you, couldn't you just use that repo, which will also have the cf dialect? I'm hesitant to creat a new repo for cf right now, only because, it's really nothing yet. But on the other hand, it isn't much of a work at all for me to create one. What do you propose should be on that repo? We have some "general purpose dialects" ? like arith and cf ? like pliron-gp-dialects ?

[rahulmutt]

Yes it'd be nice to have a separate repo for general purpose dialects like arith and cf.

Other naming suggestions:

• pilron-std-dialects
• pilron-standard-dialects
• pilron-general-dialects
• pilron-common-dialects

Feel free to pick whatever sounds good to you. It's ok if the cf dialect doesn't have much, I can submit PRs to add more. It'd be nice to have a doc per dialect that describes what sorts of ops are ok and what types of computations the dialect is meant to express.

[vaivaswatha]

pliron-common-dialects sounds nice. I'm not keen on "standard" as that would imply that it's special / official, but it shouldn't be. It'll just be commonly useful, but nothing more.

Okay, I'll create one and post back here.