[MLIR] [Python] `ir.Value` is now generic in the type of the value it holds by superbobry · Pull Request #166148 · llvm/llvm-project

superbobry · 2025-11-03T10:57:45Z

This makes it similar to mlir::TypedValue in the MLIR C++ API and allows users to be more specific about the values they produce or accept.

llvmbot · 2025-11-03T10:58:18Z

@llvm/pr-subscribers-mlir-core

@llvm/pr-subscribers-mlir

Author: Sergei Lebedev (superbobry)

Changes

This makes it similar to mlir::TypedValue in the MLIR C++ API and allows users to be more specific about the values they produce or accept.

Full diff: https://github.com/llvm/llvm-project/pull/166148.diff

1 Files Affected:

(modified) mlir/lib/Bindings/Python/IRCore.cpp (+14-8)

diff --git a/mlir/lib/Bindings/Python/IRCore.cpp b/mlir/lib/Bindings/Python/IRCore.cpp
index cda4fe19c16f8..1ef058af2c1ef 100644
--- a/mlir/lib/Bindings/Python/IRCore.cpp
+++ b/mlir/lib/Bindings/Python/IRCore.cpp
@@ -18,6 +18,7 @@
 #include "mlir/Bindings/Python/Nanobind.h"
 #include "mlir/Bindings/Python/NanobindAdaptors.h"
 #include "nanobind/nanobind.h"
+#include "nanobind/typing.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallVector.h"
 
@@ -4278,7 +4279,10 @@ void mlir::python::populateIRCore(nb::module_ &m) {
   //----------------------------------------------------------------------------
   // Mapping of Value.
   //----------------------------------------------------------------------------
-  nb::class_<PyValue>(m, "Value")
+  m.attr("_T") = nb::type_var("_T", nb::arg("bound") = m.attr("Type"));
+
+  nb::class_<PyValue>(m, "Value", nb::is_generic(),
+                      nb::sig("class Value(Generic[_T])"))
       .def(nb::init<PyValue &>(), nb::keep_alive<0, 1>(), nb::arg("value"))
       .def_prop_ro(MLIR_PYTHON_CAPI_PTR_ATTR, &PyValue::getCapsule)
       .def_static(MLIR_PYTHON_CAPI_FACTORY_ATTR, &PyValue::createFromCapsule)
@@ -4371,18 +4375,20 @@ void mlir::python::populateIRCore(nb::module_ &m) {
             return printAccum.join();
           },
           nb::arg("state"), kGetNameAsOperand)
-      .def_prop_ro("type",
-                   [](PyValue &self) -> nb::typed<nb::object, PyType> {
-                     return PyType(self.getParentOperation()->getContext(),
-                                   mlirValueGetType(self.get()))
-                         .maybeDownCast();
-                   })
+      .def_prop_ro(
+          "type",
+          [](PyValue &self) {
+            return PyType(self.getParentOperation()->getContext(),
+                          mlirValueGetType(self.get()))
+                .maybeDownCast();
+          },
+          nb::sig("def type(self) -> _T"))
       .def(
           "set_type",
           [](PyValue &self, const PyType &type) {
             return mlirValueSetType(self.get(), type);
           },
-          nb::arg("type"))
+          nb::arg("type"), nb::sig("def set_type(self, type: _T)"))
       .def(
           "replace_all_uses_with",
           [](PyValue &self, PyValue &with) {

github-actions · 2025-11-11T22:12:50Z

✅ With the latest revision this PR passed the C/C++ code formatter.

mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp

makslevental

LGTM (modulo one nit)

… holds This makes it similar to `mlir::TypedValue` in the MLIR C++ API and allows users to be more specific about the values they produce or accept. Co-authored-by: Maksim Levental <maksim.levental@gmail.com>

amd-eochoalo · 2025-11-13T18:39:33Z

mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp

+        if (std::strcmp(kind, "operand") == 0) {
+          StringRef pythonType = getPythonType(element.constraint.getCppType());
+          if (!pythonType.empty())
+            type += "[" + pythonType.str() + "]";
+        }


I think there is an error here. type may be "_ods_ir.OpOperandList" here which is not Generic.

Fixed here #167930

Thanks for the fix!

Change in #166148 caused breaks for some other types. Specifically this error was seen in a downstream project ``` _ods_ir.OpOperandList[_ods_ir.IntegerType]: TypeError: type 'iree.compiler._mlir_libs._mlir.ir.OpOperandList' is not subscriptable ``` This PR tries to make those changes not affect the other types --------- Signed-off-by: Nirvedh Meshram <nirvedh@gmail.com>

…(#167930) Change in llvm/llvm-project#166148 caused breaks for some other types. Specifically this error was seen in a downstream project ``` _ods_ir.OpOperandList[_ods_ir.IntegerType]: TypeError: type 'iree.compiler._mlir_libs._mlir.ir.OpOperandList' is not subscriptable ``` This PR tries to make those changes not affect the other types --------- Signed-off-by: Nirvedh Meshram <nirvedh@gmail.com>

Change in llvm#166148 caused breaks for some other types. Specifically this error was seen in a downstream project ``` _ods_ir.OpOperandList[_ods_ir.IntegerType]: TypeError: type 'iree.compiler._mlir_libs._mlir.ir.OpOperandList' is not subscriptable ``` This PR tries to make those changes not affect the other types --------- Signed-off-by: Nirvedh Meshram <nirvedh@gmail.com>

@PragmaTwice

…otations (#356) This PR adds support for using the upstream types as bare arg annotions for `func.func`s: ```python @func def f_same_type_args( x: RankedTensorType[[2, 3], F32Type], y: RankedTensorType[[2, 3], F32Type], ) -> RankedTensorType[[2, 3], F32Type]: ... ``` emits ```mlir func.func private @f_same_type_args(tensor<2x3xf32>, tensor<2x3xf32>) -> tensor<2x3xf32> ``` This is thanks to a PR @PragmaTwice recently landed upstream (I can't remember which one exactly...). As well, we now support the completely "correct" version of this: ```python @func def f_mixed_args( a: Value[F32Type], b: Value[VectorType[[4], F32Type]], c: Value[MemRefType[[2, 3], F32Type]], ): return b ``` where tab-complete will now actually do the correct thing as well, and the IR emitted is ```mlir func.func @f_mixed_args(%[[A:.*]]: f32, %[[B:.*]]: vector<4xf32>, %[[C:.*]]: memref<2x3xf32>) -> vector<4xf32> ``` This is thanks to a [PR](llvm/llvm-project#166148) @superbobry landed recently. **NOTE**: this actually fixes a long-standing issue with the bindings/extras/DSL: namely that you could not write `@func`s without having an active `ir.Context` (because you cannot actually instantiate `ir.Type` without an active `ir.Context`). Since these `GenericAlias`es are unevaluated until we actually emit the `func.func`, we can now write these safely without an active context.

superbobry requested review from makslevental and rolfmorel as code owners November 3, 2025 10:57

llvmbot added the mlir label Nov 3, 2025

superbobry force-pushed the typed-value branch from e8d2178 to 7eec476 Compare November 3, 2025 10:58

superbobry force-pushed the typed-value branch from 7eec476 to 46e29cb Compare November 11, 2025 10:50

superbobry requested review from ftynse and stellaraccident as code owners November 11, 2025 10:50

llvmbot added the mlir:core MLIR Core Infrastructure label Nov 11, 2025

superbobry force-pushed the typed-value branch from 46e29cb to 27e8308 Compare November 11, 2025 22:11

superbobry force-pushed the typed-value branch from 27e8308 to 35ea06e Compare November 12, 2025 09:18

makslevental reviewed Nov 12, 2025

View reviewed changes

mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp Show resolved Hide resolved

makslevental approved these changes Nov 12, 2025

View reviewed changes

superbobry force-pushed the typed-value branch from 5a54a04 to 1091d12 Compare November 12, 2025 21:23

[MLIR] [Python] ir.Value is now generic in the type of the value it…

bce885c

… holds This makes it similar to `mlir::TypedValue` in the MLIR C++ API and allows users to be more specific about the values they produce or accept. Co-authored-by: Maksim Levental <maksim.levental@gmail.com>

superbobry force-pushed the typed-value branch from 1091d12 to bce885c Compare November 13, 2025 13:06

superbobry merged commit 31536e6 into llvm:main Nov 13, 2025
10 checks passed

amd-eochoalo reviewed Nov 13, 2025

View reviewed changes

nirvedhmeshram mentioned this pull request Nov 13, 2025

[mlir][python] Fix ir.Value type to not break other types #167930

Merged

makslevental mentioned this pull request Dec 1, 2025

[MLIR][Python] Add a DSL for defining dialects in Python bindings #169045

Merged

makslevental mentioned this pull request Mar 8, 2026

[eudsl-python-extras] support types as GenericAlias for input arg annotations llvm/eudsl#356

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[MLIR] [Python] `ir.Value` is now generic in the type of the value it holds#166148

[MLIR] [Python] `ir.Value` is now generic in the type of the value it holds#166148
superbobry merged 1 commit intollvm:mainfrom
superbobry:typed-value

superbobry commented Nov 3, 2025

Uh oh!

llvmbot commented Nov 3, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Nov 11, 2025 •

edited

Loading

Uh oh!

Uh oh!

makslevental left a comment

Uh oh!

Uh oh!

amd-eochoalo Nov 13, 2025

Uh oh!

amd-eochoalo Nov 13, 2025

Uh oh!

superbobry Nov 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

superbobry commented Nov 3, 2025

Uh oh!

llvmbot commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

makslevental left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

amd-eochoalo Nov 13, 2025

Choose a reason for hiding this comment

Uh oh!

amd-eochoalo Nov 13, 2025

Choose a reason for hiding this comment

Uh oh!

superbobry Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

llvmbot commented Nov 3, 2025 •

edited

Loading

github-actions bot commented Nov 11, 2025 •

edited

Loading