[Mlir-commits] [mlir] [MLIR][Transform] apply_registered_pass op's options as a dict (PR #143159)

Rolf Morel llvmlistbot at llvm.org
Sun Jun 8 13:11:36 PDT 2025


================
@@ -214,6 +214,88 @@ def __init__(
         super().__init__(_get_op_results_or_values(operands), loc=loc, ip=ip)
 
 
+ at register_attribute_builder("ParamOperandIndexAttr")
+def _paramOperandIndexAttr(x: int, context) -> Attribute:
+    return Attribute.parse(f"#transform.param_operand_index<{x}>", context=context)
+
+
+ at _ods_cext.register_operation(_Dialect, replace=True)
+class ApplyRegisteredPassOp(ApplyRegisteredPassOp):
+    def __init__(
+        self,
+        result: Type,
+        pass_name: Union[str, StringAttr],
+        target: Union[Operation, Value, OpView],
+        *,
+        options: Dict[
+            Union[str, StringAttr],
+            Union[Attribute, Value, Operation, OpView],
+        ] = {},
----------------
rolfmorel wrote:

Re. 1.:
 * Sure, if you - or a called function - would modify the argument that's a problem. I still feel the wrapping of every option in an `Optional` smells off, but as it is such a common pattern I have now adopted it here as well.
  
 Re. 2:
 *   IMO, the default Python-bindings should reflect the syntax of the normal ops as much as possible. This is so that the Python using the bindings by default looks very similar to normal syntax. So, while `**kwargs` _are_ a nice way to specify options, to me the options are keyed behind the `options` key in the current pretty-printed format. Anybody is free to provide a wrapper along the lines of yours though, potentially even in an `extras` sub-module. (Though watch out for arguments which happened to have the names `loc` and `ip` though.)

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


More information about the Mlir-commits mailing list