[Mlir-commits] [mlir] [MLIR][Python] Add a DSL for defining IRDL dialects in Python bindings (PR #169045)

[llvmlistbot at llvm.org]

PragmaTwice wrote:

TL;DR:

```python
class MyInt(irdsl.Dialect, name="myint"):
  pass

iattr = irdsl.BaseName("#builtin.integer")
i32 = irdsl.Is[IntegerType.get_signless](32)

class ConstantOp(MyInt.Operation, name="constant"):
    value = irdsl.Attribute(iattr)
    cst = irdsl.Result(i32)

class AddOp(MyInt.Operation, name="add"):
    lhs = irdsl.Operand(i32)
    rhs = irdsl.Operand(i32)
    res = irdsl.Result(i32)

MyInt.load()
```

The latest patch mainly addresses two issues:

1. `irdsl.Dialect` is now defined in a way similar to `irdsl.Operation`, i.e., through inheritance. This makes future extensions possible.

2. `irdsl.Is` now accepts a callable rather than a concrete `Type`/`Attribute`, to avoid the requirement for an `ir.Context`. This is a lightweight solution that keeps us from having to adapt every `Type`/`Attribute` kind individually.

> should we maybe be adhering more closely to the syntax used by Python's @dataclass classes?

Looks good, but I’d prefer to keep the DSL relatively lightweight and concise. Also, it seems default values aren’t supported at the `irdl` layer, so for now we can only mark things as optional—we can’t provide an actual default value directly.

> This too raises another option: forgoing special irdsl.Operand, irdsl.Attribute and irdsl.Result types and instead just using mlir.ir.OpOperand, mlir.ir.Attribute and mlir.ir.OpResult as types which are (already) parametric and which we can make to be or-ed and &-ed.

This sounds really nice, but it seems like a fairly large piece of work. We can move in that direction, but it feels outside the scope of a lightweight DSL.



https://github.com/llvm/llvm-project/pull/169045