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

[Rolf Morel]

================
@@ -0,0 +1,308 @@
+# RUN: %PYTHON %s 2>&1 | FileCheck %s
+
+from mlir.ir import *
+from mlir.dialects.irdl import dsl as irdsl
+from mlir.dialects import arith
+import sys
+
+
+def run(f):
+    print("\nTEST:", f.__name__, file=sys.stderr)
+    with Context():
+        f()
+
+
+# CHECK: TEST: testMyInt
+ at run
+def testMyInt():
+    myint = irdsl.Dialect("myint")
+    iattr = irdsl.BaseName("#builtin.integer")
+    i32 = irdsl.IsType(IntegerType.get_signless(32))
+
+    @myint.op("constant")
+    class ConstantOp:
+        value = irdsl.Attribute(iattr)
+        cst = irdsl.Result(i32)
----------------
rolfmorel wrote:

How about if these op definition classes, e.g. this `ConstantOp`, inherited from `OpView` (potentially indirectly, e.g. via `irdsl.Operation`)? Would that allow us to get away from generated classes? Whether this is a net positive is due to how much meta-programming is involved in modifying the class's definition. My hope is that this would be a lesser magic than that of "your op is actually instantiated by a class generated in the background".

The decorator would be responsible for connecting the op definition to the dialect object _and_ for triggering the meta-programming, i.e. any necessary class definition modifications. If users apply the decorator to a class that doesn't extend the appropriate classes, that could be an assertion failure, IMO.


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