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

[Fehr Mathieu]

math-fehr wrote:

Sorry for the delay! I'll have more time to review this in 2 days, but otherwise I think from the examples you showed the design looks good!

I think the main lessons we had and challenges with xdsl are variables and constraints. These are things that are likely only come up much later, but I think it's useful to know for context. One thing to note is that we make sure that pyright type checks 100% of our code, so we have additional challenges that may be irrelevant for you.

### Type/Attribute constraints

I think a lot of work we did in type or attribute constraints was to make `pyright` happy. We have an `AttrConstraint[T]` class, and a way to convert from Python types to this `AttrConstraint`. In particular, this is entirely typed by pyright, so when we pass an `AttrConstraint[IntegerType]` to `my_result = result_def(...)`, pyright knows that `my_op.my_result` will have the type `SSAValue[IntegerType]`. I'm not sure how much this would be useful here (I haven't looked at the python bindings in a long time), but it is quite nice to have.

Another thing is generic types, which I'm not sure the Python bindings have? We can write `operand_def(VectorType[IntegerType[32]])` which is quite nice to have. Otherwise, you'll have to write functions like `operand_def(VectorType.constraint(IntegerType.constraint(32)))` which essentially will create an `AttrConstraint` object so that you can convert it to IRDL properly.

### Variables

For variables, the current design we have is the following. This is probably the thing I would love to see the most in `irdsl`:
```python
@irdl_op_definition
class GenericConstraintVarOp(IRDLOperation):
    name = "test.constraint_var_op"

    T: ClassVar = VarConstraint("T", base(IntegerType))

    operand = operand_def(VectorType[T])
    result = result_def(T)
```
Here, we use a `VarConstraint` to specify that `T` should be the same in both the operand and the result. So if your operand is `vector<9xi32>` you can infer your result to be `i32`. We use this inference a lot in our declarative assembly format. We used `ClassVar` so that pyright wouldn't complain, so I think you could skip this for irdsl if you do not care about it. We use an explicit name for the constraint so that two variables can be distinguished when introspecting the class definition.

I guess like in your case you could put it outside the class definition, but we do have generic types in our operations/attributes so `AddI[T]` might have operands that depend on `T`.

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