clarify difference between Kirin vs MLIR, xDSL

[Roger-luo]

I think this is a common question being asked from people who worked with MLIR and especially xDSL. I intend to turn this issue into a blog post at some point but writing it here first so we can get comments easily.

Kirin does not aim to be MLIR in Python (a.k.a xDSL)

the primary audience here are scientists, we don't want to be exactly compatible with MLIR. This is because existing ecosystem in MLIR are mostly about array programming, GPU, FPGA, automatic differentiation etc. compiler infrastructure around this part of application does not have a strong need in general scientific tasks (or say quantum).

Extra things Kirin provides

While standard things like passes (i.e. constant prop, CSE, DCE), basic data structures (i.e. IList, tuple, etc.) are useful, scientific community usually prefers dynamic languages over static ones. This as a result causing the difference in these builtin dialects.

Builtin Dialects designed to model dynamic langauges

For example, we allow embedding a method instance inside the IR like how Julia does it. This allows one dynamically point to the Method object within Python without worrying about how to static compile/serialize it. (It does have disadvantage tho). This also allows us to support recursion and closures very easily. Doing so requires modifying the data structure a little bit on what it means by an attribute, and what is the minimal compile unit (in our case, this does not have to be a ModuleOp like MLIR or xDSL).

On the other hand, we still appreciate the ability of being statically compiled (at least most of the program!). So there is type inference (with generics) and constant propagation.

Abstract/Concrete Interpretation

The downside of accepting certain dynamism is we cannot modify methods other than the current method anymore, e.g

def main(x):
    foo(x)
    bar(x)
    foo(x)

we can rewrite the IR of main to whatever we want, but we cannot touch foo or bar anymore. So things like interprocedure constant prop is not possible by doing a rewrite from some statement into Constant statement. Instead we need abstract interpretation that stores the constant propagation result somewhere outside the IR without modifying the callee. This turns out to require a more complete interpreter that supports actual stack frames etc. (so we can understand function calls)

AST Lowering framework

Because our audience are primarily scientists. People do not expect writing the code in an SSA IR text format. They expect just writing some Python. But creating a Python frontend over and over again for different eDSLs is annoying, so we choose to unify the lowering via a framework and automatically provide a default lowering transform from Python AST. So you don't have to modify packages like autograph or malt.

Conclusion

There are certainly more design decisions made differently because of this primarily difference in its vision. We don't aim to be MLIR in Python, so if you are looking for something built compatible with MLIR and use it for faster MLIR development Kirin is unlikely to be the first choice. It is not a framework designed for compiler experts.

But how are you planning to integrate with MLIR then? The integration is more about porting builtin dialects into MLIR and ideally via auto-generated IRDL dialect instead of being compatible in IR definition. Then Kirin will serve as a frontend for MLIR-based compilers given the scope of writing Python kernel functions instead of a tool expedite development of MLIR-based compilers.

[Roger-luo]

need to put this in documentation.