[all-commits] [llvm/llvm-project] b544ad: [MLIR] [Python] Added a way to extend MLIR->Python...

[Sergei Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b544ad57039588d0fe24a1f512202cc5c0bd3a67
      https://github.com/llvm/llvm-project/commit/b544ad57039588d0fe24a1f512202cc5c0bd3a67
  Author: Sergei Lebedev <185856+superbobry at users.noreply.github.com>
  Date:   2026-03-31 (Tue, 31 Mar 2026)

  Changed paths:
    M mlir/docs/Bindings/Python.md
    A mlir/include/mlir/Bindings/Python/PythonBindings.td
    M mlir/test/mlir-tblgen/op-python-bindings.td
    M mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp

  Log Message:
  -----------
  [MLIR] [Python] Added a way to extend MLIR->Python type mappings (#189368)

The idea is to use TableGen records for both custom type constraints and
attributes:

* `PythonTypeName` is for type constraints, while
* `PythonAttrType` is for attributes.

The key types differ between these two records. `PythonTypeName` is
keyed by C++ type because multiple type constraints map to the same C++
type (e.g. `I32` and `I64` both map to `::mlir::IntegerType`), so a
single entry covers all of them. `PythonAttrType` is keyed by TableGen
def name because different attributes can share the same C++ storage
type but need distinct Python types (e.g. `I32ArrayAttr` and
`StrArrayAttr` are both `::mlir::ArrayAttr`).

We could in theory reimplement `getPythonAttrName` using the same
approach, but I decided to leave it for future PRs.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications