2020-08-16 18:49:28 -07:00
|
|
|
//===- IRModules.h - IR Submodules of pybind module -----------------------===//
|
|
|
|
|
//
|
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
|
//
|
2023-12-11 09:43:08 +00:00
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2020-08-16 18:49:28 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#ifndef MLIR_BINDINGS_PYTHON_IRMODULES_H
|
|
|
|
|
#define MLIR_BINDINGS_PYTHON_IRMODULES_H
|
|
|
|
|
|
2022-11-08 16:55:06 -05:00
|
|
|
#include <optional>
|
2025-03-10 11:19:23 +01:00
|
|
|
#include <sstream>
|
2022-01-14 01:35:55 +00:00
|
|
|
#include <utility>
|
2020-10-28 23:16:36 -07:00
|
|
|
#include <vector>
|
|
|
|
|
|
2023-05-26 10:23:17 -05:00
|
|
|
#include "Globals.h"
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
#include "NanobindUtils.h"
|
2021-01-07 11:09:09 +01:00
|
|
|
#include "mlir-c/AffineExpr.h"
|
2020-12-14 18:43:05 +08:00
|
|
|
#include "mlir-c/AffineMap.h"
|
2025-09-20 14:47:32 -04:00
|
|
|
#include "mlir-c/BuiltinAttributes.h"
|
2022-01-03 16:39:58 -08:00
|
|
|
#include "mlir-c/Diagnostics.h"
|
2020-08-16 18:49:28 -07:00
|
|
|
#include "mlir-c/IR.h"
|
2021-01-25 18:17:19 +01:00
|
|
|
#include "mlir-c/IntegerSet.h"
|
2024-06-11 07:45:12 -07:00
|
|
|
#include "mlir-c/Transforms.h"
|
2024-12-20 23:32:32 -05:00
|
|
|
#include "mlir/Bindings/Python/Nanobind.h"
|
2025-03-10 11:19:23 +01:00
|
|
|
#include "mlir/Bindings/Python/NanobindAdaptors.h"
|
2020-09-18 00:21:09 -07:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2025-03-10 11:19:23 +01:00
|
|
|
#include "llvm/Support/ThreadPool.h"
|
2020-08-16 18:49:28 -07:00
|
|
|
|
2020-08-16 20:53:45 -07:00
|
|
|
namespace mlir {
|
|
|
|
|
namespace python {
|
2020-08-16 18:49:28 -07:00
|
|
|
|
2020-09-20 21:25:46 -07:00
|
|
|
class PyBlock;
|
2022-01-03 16:39:58 -08:00
|
|
|
class PyDiagnostic;
|
|
|
|
|
class PyDiagnosticHandler;
|
2020-10-28 23:16:36 -07:00
|
|
|
class PyInsertionPoint;
|
2020-09-20 21:25:46 -07:00
|
|
|
class PyLocation;
|
2020-10-31 23:40:25 -07:00
|
|
|
class DefaultingPyLocation;
|
2020-08-16 18:49:28 -07:00
|
|
|
class PyMlirContext;
|
2020-10-31 23:40:25 -07:00
|
|
|
class DefaultingPyMlirContext;
|
2020-08-18 17:23:46 -07:00
|
|
|
class PyModule;
|
2020-09-18 18:38:21 -07:00
|
|
|
class PyOperation;
|
2023-10-25 07:17:56 +02:00
|
|
|
class PyOperationBase;
|
2020-09-20 21:25:46 -07:00
|
|
|
class PyType;
|
2021-11-02 12:39:36 +01:00
|
|
|
class PySymbolTable;
|
2020-10-20 11:21:05 +02:00
|
|
|
class PyValue;
|
2020-08-16 18:49:28 -07:00
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
/// Template for a reference to a concrete type which captures a python
|
|
|
|
|
/// reference to its underlying python object.
|
|
|
|
|
template <typename T>
|
|
|
|
|
class PyObjectRef {
|
2020-09-18 00:21:09 -07:00
|
|
|
public:
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
PyObjectRef(T *referrent, nanobind::object object)
|
2020-09-18 18:38:21 -07:00
|
|
|
: referrent(referrent), object(std::move(object)) {
|
|
|
|
|
assert(this->referrent &&
|
|
|
|
|
"cannot construct PyObjectRef with null referrent");
|
|
|
|
|
assert(this->object && "cannot construct PyObjectRef with null object");
|
|
|
|
|
}
|
2023-12-11 09:43:08 +00:00
|
|
|
PyObjectRef(PyObjectRef &&other) noexcept
|
2020-09-18 18:38:21 -07:00
|
|
|
: referrent(other.referrent), object(std::move(other.object)) {
|
|
|
|
|
other.referrent = nullptr;
|
|
|
|
|
assert(!other.object);
|
|
|
|
|
}
|
|
|
|
|
PyObjectRef(const PyObjectRef &other)
|
|
|
|
|
: referrent(other.referrent), object(other.object /* copies */) {}
|
2022-01-14 01:35:35 +00:00
|
|
|
~PyObjectRef() = default;
|
2020-09-18 00:21:09 -07:00
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
int getRefCount() {
|
|
|
|
|
if (!object)
|
|
|
|
|
return 0;
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
return Py_REFCNT(object.ptr());
|
2020-09-18 18:38:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Releases the object held by this instance, returning it.
|
|
|
|
|
/// This is the proper thing to return from a function that wants to return
|
|
|
|
|
/// the reference. Note that this does not work from initializers.
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object releaseObject() {
|
2020-09-18 18:38:21 -07:00
|
|
|
assert(referrent && object);
|
|
|
|
|
referrent = nullptr;
|
|
|
|
|
auto stolen = std::move(object);
|
|
|
|
|
return stolen;
|
|
|
|
|
}
|
2020-09-18 00:21:09 -07:00
|
|
|
|
2020-10-28 23:16:36 -07:00
|
|
|
T *get() { return referrent; }
|
2020-09-18 18:38:21 -07:00
|
|
|
T *operator->() {
|
|
|
|
|
assert(referrent && object);
|
|
|
|
|
return referrent;
|
|
|
|
|
}
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object getObject() {
|
2020-09-18 18:38:21 -07:00
|
|
|
assert(referrent && object);
|
|
|
|
|
return object;
|
|
|
|
|
}
|
|
|
|
|
operator bool() const { return referrent && object; }
|
2020-09-18 00:21:09 -07:00
|
|
|
|
2025-09-22 15:55:43 -04:00
|
|
|
using NBTypedT = nanobind::typed<nanobind::object, T>;
|
|
|
|
|
|
2020-09-18 00:21:09 -07:00
|
|
|
private:
|
2020-09-18 18:38:21 -07:00
|
|
|
T *referrent;
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object object;
|
2020-09-18 00:21:09 -07:00
|
|
|
};
|
|
|
|
|
|
2020-10-28 23:16:36 -07:00
|
|
|
/// Tracks an entry in the thread context stack. New entries are pushed onto
|
2020-10-31 23:40:25 -07:00
|
|
|
/// here for each with block that activates a new InsertionPoint, Context or
|
|
|
|
|
/// Location.
|
|
|
|
|
///
|
|
|
|
|
/// Pushing either a Location or InsertionPoint also pushes its associated
|
|
|
|
|
/// Context. Pushing a Context will not modify the Location or InsertionPoint
|
|
|
|
|
/// unless if they are from a different context, in which case, they are
|
|
|
|
|
/// cleared.
|
2020-10-28 23:16:36 -07:00
|
|
|
class PyThreadContextEntry {
|
|
|
|
|
public:
|
2020-10-31 23:40:25 -07:00
|
|
|
enum class FrameKind {
|
|
|
|
|
Context,
|
|
|
|
|
InsertionPoint,
|
|
|
|
|
Location,
|
|
|
|
|
};
|
|
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
PyThreadContextEntry(FrameKind frameKind, nanobind::object context,
|
|
|
|
|
nanobind::object insertionPoint,
|
|
|
|
|
nanobind::object location)
|
2020-10-31 23:40:25 -07:00
|
|
|
: context(std::move(context)), insertionPoint(std::move(insertionPoint)),
|
|
|
|
|
location(std::move(location)), frameKind(frameKind) {}
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Gets the top of stack context and return nullptr if not defined.
|
2020-10-31 23:40:25 -07:00
|
|
|
static PyMlirContext *getDefaultContext();
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Gets the top of stack insertion point and return nullptr if not defined.
|
2020-10-31 23:40:25 -07:00
|
|
|
static PyInsertionPoint *getDefaultInsertionPoint();
|
|
|
|
|
|
|
|
|
|
/// Gets the top of stack location and returns nullptr if not defined.
|
|
|
|
|
static PyLocation *getDefaultLocation();
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
PyMlirContext *getContext();
|
|
|
|
|
PyInsertionPoint *getInsertionPoint();
|
2020-10-31 23:40:25 -07:00
|
|
|
PyLocation *getLocation();
|
|
|
|
|
FrameKind getFrameKind() { return frameKind; }
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Stack management.
|
2020-10-31 23:40:25 -07:00
|
|
|
static PyThreadContextEntry *getTopOfStack();
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object pushContext(nanobind::object context);
|
2020-10-31 23:40:25 -07:00
|
|
|
static void popContext(PyMlirContext &context);
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object pushInsertionPoint(nanobind::object insertionPoint);
|
2020-10-31 23:40:25 -07:00
|
|
|
static void popInsertionPoint(PyInsertionPoint &insertionPoint);
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object pushLocation(nanobind::object location);
|
2020-10-31 23:40:25 -07:00
|
|
|
static void popLocation(PyLocation &location);
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Gets the thread local stack.
|
|
|
|
|
static std::vector<PyThreadContextEntry> &getStack();
|
|
|
|
|
|
|
|
|
|
private:
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static void push(FrameKind frameKind, nanobind::object context,
|
|
|
|
|
nanobind::object insertionPoint, nanobind::object location);
|
2020-10-31 23:40:25 -07:00
|
|
|
|
2020-10-28 23:16:36 -07:00
|
|
|
/// An object reference to the PyContext.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object context;
|
2020-10-28 23:16:36 -07:00
|
|
|
/// An object reference to the current insertion point.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object insertionPoint;
|
2020-10-31 23:40:25 -07:00
|
|
|
/// An object reference to the current location.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object location;
|
2020-10-31 23:40:25 -07:00
|
|
|
// The kind of push that was performed.
|
|
|
|
|
FrameKind frameKind;
|
2020-10-28 23:16:36 -07:00
|
|
|
};
|
2020-09-18 18:38:21 -07:00
|
|
|
|
2025-03-10 11:19:23 +01:00
|
|
|
/// Wrapper around MlirLlvmThreadPool
|
|
|
|
|
/// Python object owns the C++ thread pool
|
|
|
|
|
class PyThreadPool {
|
|
|
|
|
public:
|
|
|
|
|
PyThreadPool() {
|
|
|
|
|
ownedThreadPool = std::make_unique<llvm::DefaultThreadPool>();
|
|
|
|
|
}
|
|
|
|
|
PyThreadPool(const PyThreadPool &) = delete;
|
|
|
|
|
PyThreadPool(PyThreadPool &&) = delete;
|
|
|
|
|
|
|
|
|
|
int getMaxConcurrency() const { return ownedThreadPool->getMaxConcurrency(); }
|
|
|
|
|
MlirLlvmThreadPool get() { return wrap(ownedThreadPool.get()); }
|
|
|
|
|
|
|
|
|
|
std::string _mlir_thread_pool_ptr() const {
|
|
|
|
|
std::stringstream ss;
|
|
|
|
|
ss << ownedThreadPool.get();
|
|
|
|
|
return ss.str();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
std::unique_ptr<llvm::ThreadPoolInterface> ownedThreadPool;
|
|
|
|
|
};
|
|
|
|
|
|
2020-08-16 18:49:28 -07:00
|
|
|
/// Wrapper around MlirContext.
|
2020-10-28 23:16:36 -07:00
|
|
|
using PyMlirContextRef = PyObjectRef<PyMlirContext>;
|
2020-08-16 18:49:28 -07:00
|
|
|
class PyMlirContext {
|
|
|
|
|
public:
|
2020-09-18 00:21:09 -07:00
|
|
|
PyMlirContext() = delete;
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
PyMlirContext(MlirContext context);
|
2020-09-18 00:21:09 -07:00
|
|
|
PyMlirContext(const PyMlirContext &) = delete;
|
|
|
|
|
PyMlirContext(PyMlirContext &&) = delete;
|
|
|
|
|
|
|
|
|
|
/// Returns a context reference for the singleton PyMlirContext wrapper for
|
Revert "[mlir][python] Make the Context/Operation capsule creation methods work as documented. (#76010)"
This reverts commit bbc29768683b394b34600347f46be2b8245ddb30.
This change seems to be at odds with the non-owning part semantics of
MlirOperation in C API. Since downstream clients can only take and
return MlirOperation, it does not sound correct to force all returns of
MlirOperation transfer ownership. Specifically, this makes it impossible
for downstreams to implement IR-traversing functions that, e.g., look at
neighbors of an operation.
The following patch triggers the exception, and there does not seem to
be an alternative way for a downstream binding writer to express this:
```
diff --git a/mlir/lib/Bindings/Python/IRCore.cpp b/mlir/lib/Bindings/Python/IRCore.cpp
index 39757dfad5be..2ce640674245 100644
--- a/mlir/lib/Bindings/Python/IRCore.cpp
+++ b/mlir/lib/Bindings/Python/IRCore.cpp
@@ -3071,6 +3071,11 @@ void mlir::python::populateIRCore(py::module &m) {
py::arg("successors") = py::none(), py::arg("regions") = 0,
py::arg("loc") = py::none(), py::arg("ip") = py::none(),
py::arg("infer_type") = false, kOperationCreateDocstring)
+ .def("_get_first_in_block", [](PyOperation &self) -> MlirOperation {
+ MlirBlock block = mlirOperationGetBlock(self.get());
+ MlirOperation first = mlirBlockGetFirstOperation(block);
+ return first;
+ })
.def_static(
"parse",
[](const std::string &sourceStr, const std::string &sourceName,
diff --git a/mlir/test/python/ir/operation.py b/mlir/test/python/ir/operation.py
index f59b1a26ba48..6b12b8da5c24 100644
--- a/mlir/test/python/ir/operation.py
+++ b/mlir/test/python/ir/operation.py
@@ -24,6 +24,25 @@ def expect_index_error(callback):
except IndexError:
pass
+@run
+def testCustomBind():
+ ctx = Context()
+ ctx.allow_unregistered_dialects = True
+ module = Module.parse(
+ r"""
+ func.func @f1(%arg0: i32) -> i32 {
+ %1 = "custom.addi"(%arg0, %arg0) : (i32, i32) -> i32
+ return %1 : i32
+ }
+ """,
+ ctx,
+ )
+ add = module.body.operations[0].regions[0].blocks[0].operations[0]
+ op = add.operation
+ # This will get a reference to itself.
+ f1 = op._get_first_in_block()
+
+
# Verify iterator based traversal of the op/region/block hierarchy.
# CHECK-LABEL: TEST: testTraverseOpRegionBlockIterators
```
2023-12-21 10:01:44 +00:00
|
|
|
/// the given context.
|
2020-09-18 00:21:09 -07:00
|
|
|
static PyMlirContextRef forContext(MlirContext context);
|
|
|
|
|
~PyMlirContext();
|
|
|
|
|
|
|
|
|
|
/// Accesses the underlying MlirContext.
|
|
|
|
|
MlirContext get() { return context; }
|
|
|
|
|
|
|
|
|
|
/// Gets a strong reference to this context, which will ensure it is kept
|
|
|
|
|
/// alive for the life of the reference.
|
|
|
|
|
PyMlirContextRef getRef() {
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
return PyMlirContextRef(this, nanobind::cast(this));
|
2020-09-18 00:21:09 -07:00
|
|
|
}
|
|
|
|
|
|
2020-09-28 09:08:09 -07:00
|
|
|
/// Gets a capsule wrapping the void* within the MlirContext.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2020-09-28 09:08:09 -07:00
|
|
|
|
|
|
|
|
/// Creates a PyMlirContext from the MlirContext wrapped by a capsule.
|
|
|
|
|
/// Note that PyMlirContext instances are uniqued, so the returned object
|
2020-10-12 21:19:13 -07:00
|
|
|
/// may be a pre-existing object. Ownership of the underlying MlirContext
|
|
|
|
|
/// is taken by calling this function.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object createFromCapsule(nanobind::object capsule);
|
2020-09-28 09:08:09 -07:00
|
|
|
|
2020-09-18 00:21:09 -07:00
|
|
|
/// Gets the count of live context objects. Used for testing.
|
|
|
|
|
static size_t getLiveCount();
|
|
|
|
|
|
2025-09-15 00:45:30 -04:00
|
|
|
/// Gets the count of live modules associated with this context.
|
|
|
|
|
/// Used for testing.
|
|
|
|
|
size_t getLiveModuleCount();
|
|
|
|
|
|
2020-10-31 23:40:25 -07:00
|
|
|
/// Enter and exit the context manager.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object contextEnter(nanobind::object context);
|
|
|
|
|
void contextExit(const nanobind::object &excType,
|
|
|
|
|
const nanobind::object &excVal,
|
|
|
|
|
const nanobind::object &excTb);
|
2020-09-20 21:25:46 -07:00
|
|
|
|
2022-01-03 16:39:58 -08:00
|
|
|
/// Attaches a Python callback as a diagnostic handler, returning a
|
|
|
|
|
/// registration object (internally a PyDiagnosticHandler).
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object attachDiagnosticHandler(nanobind::object callback);
|
2022-01-03 16:39:58 -08:00
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
/// Controls whether error diagnostics should be propagated to diagnostic
|
|
|
|
|
/// handlers, instead of being captured by `ErrorCapture`.
|
|
|
|
|
void setEmitErrorDiagnostics(bool value) { emitErrorDiagnostics = value; }
|
2025-09-20 14:47:32 -04:00
|
|
|
bool getEmitErrorDiagnostics() { return emitErrorDiagnostics; }
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
struct ErrorCapture;
|
|
|
|
|
|
2020-09-18 00:21:09 -07:00
|
|
|
private:
|
|
|
|
|
// Interns the mapping of live MlirContext::ptr to PyMlirContext instances,
|
|
|
|
|
// preserving the relationship that an MlirContext maps to a single
|
|
|
|
|
// PyMlirContext wrapper. This could be replaced in the future with an
|
|
|
|
|
// extension mechanism on the MlirContext for stashing user pointers.
|
|
|
|
|
// Note that this holds a handle, which does not imply ownership.
|
|
|
|
|
// Mappings will be removed when the context is destructed.
|
2020-09-18 18:38:21 -07:00
|
|
|
using LiveContextMap = llvm::DenseMap<void *, PyMlirContext *>;
|
2025-01-13 12:00:31 +01:00
|
|
|
static nanobind::ft_mutex live_contexts_mutex;
|
2020-09-18 00:21:09 -07:00
|
|
|
static LiveContextMap &getLiveContexts();
|
2020-08-16 18:49:28 -07:00
|
|
|
|
2025-09-15 00:45:30 -04:00
|
|
|
// Interns all live modules associated with this context. Modules tracked
|
|
|
|
|
// in this map are valid. When a module is invalidated, it is removed
|
|
|
|
|
// from this map, and while it still exists as an instance, any
|
|
|
|
|
// attempt to access it will raise an error.
|
|
|
|
|
using LiveModuleMap =
|
|
|
|
|
llvm::DenseMap<const void *, std::pair<nanobind::handle, PyModule *>>;
|
|
|
|
|
LiveModuleMap liveModules;
|
|
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
bool emitErrorDiagnostics = false;
|
|
|
|
|
|
2020-08-16 18:49:28 -07:00
|
|
|
MlirContext context;
|
2020-10-12 21:19:13 -07:00
|
|
|
friend class PyModule;
|
2020-09-18 18:38:21 -07:00
|
|
|
friend class PyOperation;
|
2020-09-18 00:21:09 -07:00
|
|
|
};
|
|
|
|
|
|
2020-10-31 23:40:25 -07:00
|
|
|
/// Used in function arguments when None should resolve to the current context
|
|
|
|
|
/// manager set instance.
|
|
|
|
|
class DefaultingPyMlirContext
|
|
|
|
|
: public Defaulting<DefaultingPyMlirContext, PyMlirContext> {
|
|
|
|
|
public:
|
|
|
|
|
using Defaulting::Defaulting;
|
2025-10-02 11:18:47 -04:00
|
|
|
static constexpr const char kTypeDescription[] = "Context";
|
2020-10-31 23:40:25 -07:00
|
|
|
static PyMlirContext &resolve();
|
|
|
|
|
};
|
|
|
|
|
|
2020-09-18 00:21:09 -07:00
|
|
|
/// Base class for all objects that directly or indirectly depend on an
|
|
|
|
|
/// MlirContext. The lifetime of the context will extend at least to the
|
|
|
|
|
/// lifetime of these instances.
|
|
|
|
|
/// Immutable objects that depend on a context extend this directly.
|
|
|
|
|
class BaseContextObject {
|
|
|
|
|
public:
|
2020-09-18 18:38:21 -07:00
|
|
|
BaseContextObject(PyMlirContextRef ref) : contextRef(std::move(ref)) {
|
|
|
|
|
assert(this->contextRef &&
|
|
|
|
|
"context object constructed with null context ref");
|
|
|
|
|
}
|
2020-09-18 00:21:09 -07:00
|
|
|
|
|
|
|
|
/// Accesses the context reference.
|
|
|
|
|
PyMlirContextRef &getContext() { return contextRef; }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
PyMlirContextRef contextRef;
|
2020-08-16 18:49:28 -07:00
|
|
|
};
|
|
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
/// Wrapper around an MlirLocation.
|
|
|
|
|
class PyLocation : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyLocation(PyMlirContextRef contextRef, MlirLocation loc)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), loc(loc) {}
|
|
|
|
|
|
|
|
|
|
operator MlirLocation() const { return loc; }
|
|
|
|
|
MlirLocation get() const { return loc; }
|
|
|
|
|
|
|
|
|
|
/// Enter and exit the context manager.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object contextEnter(nanobind::object location);
|
|
|
|
|
void contextExit(const nanobind::object &excType,
|
|
|
|
|
const nanobind::object &excVal,
|
|
|
|
|
const nanobind::object &excTb);
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
|
|
|
|
|
/// Gets a capsule wrapping the void* within the MlirLocation.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
|
|
|
|
|
/// Creates a PyLocation from the MlirLocation wrapped by a capsule.
|
|
|
|
|
/// Note that PyLocation instances are uniqued, so the returned object
|
|
|
|
|
/// may be a pre-existing object. Ownership of the underlying MlirLocation
|
|
|
|
|
/// is taken by calling this function.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static PyLocation createFromCapsule(nanobind::object capsule);
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirLocation loc;
|
|
|
|
|
};
|
|
|
|
|
|
2022-01-03 16:39:58 -08:00
|
|
|
/// Python class mirroring the C MlirDiagnostic struct. Note that these structs
|
|
|
|
|
/// are only valid for the duration of a diagnostic callback and attempting
|
|
|
|
|
/// to access them outside of that will raise an exception. This applies to
|
|
|
|
|
/// nested diagnostics (in the notes) as well.
|
|
|
|
|
class PyDiagnostic {
|
|
|
|
|
public:
|
|
|
|
|
PyDiagnostic(MlirDiagnostic diagnostic) : diagnostic(diagnostic) {}
|
|
|
|
|
void invalidate();
|
|
|
|
|
bool isValid() { return valid; }
|
|
|
|
|
MlirDiagnosticSeverity getSeverity();
|
|
|
|
|
PyLocation getLocation();
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::str getMessage();
|
|
|
|
|
nanobind::tuple getNotes();
|
2022-01-03 16:39:58 -08:00
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
/// Materialized diagnostic information. This is safe to access outside the
|
|
|
|
|
/// diagnostic callback.
|
|
|
|
|
struct DiagnosticInfo {
|
|
|
|
|
MlirDiagnosticSeverity severity;
|
|
|
|
|
PyLocation location;
|
|
|
|
|
std::string message;
|
|
|
|
|
std::vector<DiagnosticInfo> notes;
|
|
|
|
|
};
|
|
|
|
|
DiagnosticInfo getInfo();
|
|
|
|
|
|
2022-01-03 16:39:58 -08:00
|
|
|
private:
|
|
|
|
|
MlirDiagnostic diagnostic;
|
|
|
|
|
|
|
|
|
|
void checkValid();
|
|
|
|
|
/// If notes have been materialized from the diagnostic, then this will
|
|
|
|
|
/// be populated with the corresponding objects (all castable to
|
|
|
|
|
/// PyDiagnostic).
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
std::optional<nanobind::tuple> materializedNotes;
|
2022-01-03 16:39:58 -08:00
|
|
|
bool valid = true;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/// Represents a diagnostic handler attached to the context. The handler's
|
|
|
|
|
/// callback will be invoked with PyDiagnostic instances until the detach()
|
|
|
|
|
/// method is called or the context is destroyed. A diagnostic handler can be
|
|
|
|
|
/// the subject of a `with` block, which will detach it when the block exits.
|
|
|
|
|
///
|
|
|
|
|
/// Since diagnostic handlers can call back into Python code which can do
|
|
|
|
|
/// unsafe things (i.e. recursively emitting diagnostics, raising exceptions,
|
|
|
|
|
/// etc), this is generally not deemed to be a great user-level API. Users
|
|
|
|
|
/// should generally use some form of DiagnosticCollector. If the handler raises
|
|
|
|
|
/// any exceptions, they will just be emitted to stderr and dropped.
|
|
|
|
|
///
|
|
|
|
|
/// The unique usage of this class means that its lifetime management is
|
|
|
|
|
/// different from most other parts of the API. Instances are always created
|
|
|
|
|
/// in an attached state and can transition to a detached state by either:
|
|
|
|
|
/// a) The context being destroyed and unregistering all handlers.
|
|
|
|
|
/// b) An explicit call to detach().
|
|
|
|
|
/// The object may remain live from a Python perspective for an arbitrary time
|
|
|
|
|
/// after detachment, but there is nothing the user can do with it (since there
|
|
|
|
|
/// is no way to attach an existing handler object).
|
|
|
|
|
class PyDiagnosticHandler {
|
|
|
|
|
public:
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
PyDiagnosticHandler(MlirContext context, nanobind::object callback);
|
2022-01-03 16:39:58 -08:00
|
|
|
~PyDiagnosticHandler();
|
|
|
|
|
|
2022-08-07 15:28:18 -07:00
|
|
|
bool isAttached() { return registeredID.has_value(); }
|
2022-01-03 16:39:58 -08:00
|
|
|
bool getHadError() { return hadError; }
|
|
|
|
|
|
|
|
|
|
/// Detaches the handler. Does nothing if not attached.
|
|
|
|
|
void detach();
|
|
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object contextEnter() { return nanobind::cast(this); }
|
|
|
|
|
void contextExit(const nanobind::object &excType,
|
|
|
|
|
const nanobind::object &excVal,
|
|
|
|
|
const nanobind::object &excTb) {
|
2022-01-03 16:39:58 -08:00
|
|
|
detach();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirContext context;
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object callback;
|
2023-01-14 01:25:58 -08:00
|
|
|
std::optional<MlirDiagnosticHandlerID> registeredID;
|
2022-01-03 16:39:58 -08:00
|
|
|
bool hadError = false;
|
|
|
|
|
friend class PyMlirContext;
|
|
|
|
|
};
|
|
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
/// RAII object that captures any error diagnostics emitted to the provided
|
|
|
|
|
/// context.
|
|
|
|
|
struct PyMlirContext::ErrorCapture {
|
|
|
|
|
ErrorCapture(PyMlirContextRef ctx)
|
|
|
|
|
: ctx(ctx), handlerID(mlirContextAttachDiagnosticHandler(
|
|
|
|
|
ctx->get(), handler, /*userData=*/this,
|
|
|
|
|
/*deleteUserData=*/nullptr)) {}
|
|
|
|
|
~ErrorCapture() {
|
|
|
|
|
mlirContextDetachDiagnosticHandler(ctx->get(), handlerID);
|
|
|
|
|
assert(errors.empty() && "unhandled captured errors");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::vector<PyDiagnostic::DiagnosticInfo> take() {
|
|
|
|
|
return std::move(errors);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
PyMlirContextRef ctx;
|
|
|
|
|
MlirDiagnosticHandlerID handlerID;
|
|
|
|
|
std::vector<PyDiagnostic::DiagnosticInfo> errors;
|
|
|
|
|
|
|
|
|
|
static MlirLogicalResult handler(MlirDiagnostic diag, void *userData);
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-21 23:34:01 -07:00
|
|
|
/// Wrapper around an MlirDialect. This is exported as `DialectDescriptor` in
|
|
|
|
|
/// order to differentiate it from the `Dialect` base class which is extended by
|
|
|
|
|
/// plugins which extend dialect functionality through extension python code.
|
|
|
|
|
/// This should be seen as the "low-level" object and `Dialect` as the
|
|
|
|
|
/// high-level, user facing object.
|
|
|
|
|
class PyDialectDescriptor : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyDialectDescriptor(PyMlirContextRef contextRef, MlirDialect dialect)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), dialect(dialect) {}
|
|
|
|
|
|
|
|
|
|
MlirDialect get() { return dialect; }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirDialect dialect;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/// User-level object for accessing dialects with dotted syntax such as:
|
|
|
|
|
/// ctx.dialect.std
|
|
|
|
|
class PyDialects : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyDialects(PyMlirContextRef contextRef)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)) {}
|
|
|
|
|
|
|
|
|
|
MlirDialect getDialectForKey(const std::string &key, bool attrError);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/// User-level dialect object. For dialects that have a registered extension,
|
|
|
|
|
/// this will be the base class of the extension dialect type. For un-extended,
|
|
|
|
|
/// objects of this type will be returned directly.
|
|
|
|
|
class PyDialect {
|
|
|
|
|
public:
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
PyDialect(nanobind::object descriptor) : descriptor(std::move(descriptor)) {}
|
2020-10-21 23:34:01 -07:00
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getDescriptor() { return descriptor; }
|
2020-10-21 23:34:01 -07:00
|
|
|
|
|
|
|
|
private:
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object descriptor;
|
2020-10-21 23:34:01 -07:00
|
|
|
};
|
|
|
|
|
|
[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.
Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functionality for dialects, extensions, etc. This was done pragmatically in order to get bootstrapped and then just grew in. Downstreams largely bypass and do their own thing by providing various APIs to register things they need. Meanwhile, the C++ APIs have stabilized around this and it would make sense to follow suit.
The thing we have observed in canonical usage by downstreams is that each downstream tends to have native entry points that configure its installation to its preferences with one-stop APIs. This patch leans in to this approach with `RegisterEverything.h` and `mlir._mlir_libs._mlirRegisterEverything` being the one-stop entry points for the "upstream packages". The `_mlir_libs.__init__.py` now allows customization of the environment and Context by adding "initialization modules" to the `_mlir_libs` package. If present, `_mlirRegisterEverything` is treated as such a module. Others can be added by downstreams by adding a `_site_initialize_{i}.py` module, where '{i}' is a number starting with zero. The number will be incremented and corresponding module loaded until one is not found. Initialization modules can:
* Perform load time customization to the global environment (i.e. registering passes, hooks, etc).
* Define a `register_dialects(registry: DialectRegistry)` function that can extend the `DialectRegistry` that will be used to bootstrap the `Context`.
* Define a `context_init_hook(context: Context)` function that will be added to a list of callbacks which will be invoked after dialect registration during `Context` initialization.
Note that the `MLIRPythonExtension.RegisterEverything` is not included by default when building a downstream (its corresponding behavior was prior). For downstreams which need the default MLIR initialization to take place, they must add this back in to their Python CMake build just like they add their own components (i.e. to `add_mlir_python_common_capi_library` and `add_mlir_python_modules`). It is perfectly valid to not do this, in which case, only the things explicitly depended on and initialized by downstreams will be built/packaged. If the downstream has not been set up for this, it is recommended to simply add this back for the time being and pay the build time/package size cost.
CMake changes:
* `MLIRCAPIRegistration` -> `MLIRCAPIRegisterEverything` (renamed to signify what it does and force an evaluation: a number of places were incidentally linking this very expensive target)
* `MLIRPythonSoure.Passes` removed (without replacement: just drop)
* `MLIRPythonExtension.AllPassesRegistration` removed (without replacement: just drop)
* `MLIRPythonExtension.Conversions` removed (without replacement: just drop)
* `MLIRPythonExtension.Transforms` removed (without replacement: just drop)
Header changes:
* `mlir-c/Registration.h` is deleted. Dialect registration functionality is now in `IR.h`. Registration of upstream features are in `mlir-c/RegisterEverything.h`. When updating MLIR and a couple of downstreams, I found that proper usage was commingled so required making a choice vs just blind S&R.
Python APIs removed:
* mlir.transforms and mlir.conversions (previously only had an __init__.py which indirectly triggered `mlirRegisterTransformsPasses()` and `mlirRegisterConversionPasses()` respectively). Downstream impact: Remove these imports if present (they now happen as part of default initialization).
* mlir._mlir_libs._all_passes_registration, mlir._mlir_libs._mlirTransforms, mlir._mlir_libs._mlirConversions. Downstream impact: None expected (these were internally used).
C-APIs changed:
* mlirRegisterAllDialects(MlirContext) now takes an MlirDialectRegistry instead. It also used to trigger loading of all dialects, which was already marked with a TODO to remove -- it no longer does, and for direct use, dialects must be explicitly loaded. Downstream impact: Direct C-API users must ensure that needed dialects are loaded or call `mlirContextLoadAllAvailableDialects(MlirContext)` to emulate the prior behavior. Also see the `ir.c` test case (e.g. ` mlirContextGetOrLoadDialect(ctx, mlirStringRefCreateFromCString("func"));`).
* mlirDialectHandle* APIs were moved from Registration.h (which now is restricted to just global/upstream registration) to IR.h, arguably where it should have been. Downstream impact: include correct header (likely already doing so).
C-APIs added:
* mlirContextLoadAllAvailableDialects(MlirContext): Corresponds to C++ API with the same purpose.
Python APIs added:
* mlir.ir.DialectRegistry: Mapping for an MlirDialectRegistry.
* mlir.ir.Context.append_dialect_registry(MlirDialectRegistry)
* mlir.ir.Context.load_all_available_dialects()
* mlir._mlir_libs._mlirAllRegistration: New native extension that exposes a `register_dialects(MlirDialectRegistry)` entry point and performs all upstream pass/conversion/transforms registration on init. In this first step, we eagerly load this as part of the __init__.py and use it to monkey patch the Context to emulate prior behavior.
* Type caster and capsule support for MlirDialectRegistry
This should make it possible to build downstream Python dialects that only depend on a subset of MLIR. See: https://github.com/llvm/llvm-project/issues/56037
Here is an example PR, minimally adapting IREE to these changes: https://github.com/iree-org/iree/pull/9638/files In this situation, IREE is opting to not link everything, since it is already configuring the Context to its liking. For projects that would just like to not think about it and pull in everything, add `MLIRPythonExtension.RegisterEverything` to the list of Python sources getting built, and the old behavior will continue.
Reviewed By: mehdi_amini, ftynse
Differential Revision: https://reviews.llvm.org/D128593
2022-07-16 16:09:03 -07:00
|
|
|
/// Wrapper around an MlirDialectRegistry.
|
|
|
|
|
/// Upon construction, the Python wrapper takes ownership of the
|
|
|
|
|
/// underlying MlirDialectRegistry.
|
|
|
|
|
class PyDialectRegistry {
|
|
|
|
|
public:
|
|
|
|
|
PyDialectRegistry() : registry(mlirDialectRegistryCreate()) {}
|
|
|
|
|
PyDialectRegistry(MlirDialectRegistry registry) : registry(registry) {}
|
|
|
|
|
~PyDialectRegistry() {
|
|
|
|
|
if (!mlirDialectRegistryIsNull(registry))
|
|
|
|
|
mlirDialectRegistryDestroy(registry);
|
|
|
|
|
}
|
|
|
|
|
PyDialectRegistry(PyDialectRegistry &) = delete;
|
2023-12-11 09:43:08 +00:00
|
|
|
PyDialectRegistry(PyDialectRegistry &&other) noexcept
|
|
|
|
|
: registry(other.registry) {
|
[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.
Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functionality for dialects, extensions, etc. This was done pragmatically in order to get bootstrapped and then just grew in. Downstreams largely bypass and do their own thing by providing various APIs to register things they need. Meanwhile, the C++ APIs have stabilized around this and it would make sense to follow suit.
The thing we have observed in canonical usage by downstreams is that each downstream tends to have native entry points that configure its installation to its preferences with one-stop APIs. This patch leans in to this approach with `RegisterEverything.h` and `mlir._mlir_libs._mlirRegisterEverything` being the one-stop entry points for the "upstream packages". The `_mlir_libs.__init__.py` now allows customization of the environment and Context by adding "initialization modules" to the `_mlir_libs` package. If present, `_mlirRegisterEverything` is treated as such a module. Others can be added by downstreams by adding a `_site_initialize_{i}.py` module, where '{i}' is a number starting with zero. The number will be incremented and corresponding module loaded until one is not found. Initialization modules can:
* Perform load time customization to the global environment (i.e. registering passes, hooks, etc).
* Define a `register_dialects(registry: DialectRegistry)` function that can extend the `DialectRegistry` that will be used to bootstrap the `Context`.
* Define a `context_init_hook(context: Context)` function that will be added to a list of callbacks which will be invoked after dialect registration during `Context` initialization.
Note that the `MLIRPythonExtension.RegisterEverything` is not included by default when building a downstream (its corresponding behavior was prior). For downstreams which need the default MLIR initialization to take place, they must add this back in to their Python CMake build just like they add their own components (i.e. to `add_mlir_python_common_capi_library` and `add_mlir_python_modules`). It is perfectly valid to not do this, in which case, only the things explicitly depended on and initialized by downstreams will be built/packaged. If the downstream has not been set up for this, it is recommended to simply add this back for the time being and pay the build time/package size cost.
CMake changes:
* `MLIRCAPIRegistration` -> `MLIRCAPIRegisterEverything` (renamed to signify what it does and force an evaluation: a number of places were incidentally linking this very expensive target)
* `MLIRPythonSoure.Passes` removed (without replacement: just drop)
* `MLIRPythonExtension.AllPassesRegistration` removed (without replacement: just drop)
* `MLIRPythonExtension.Conversions` removed (without replacement: just drop)
* `MLIRPythonExtension.Transforms` removed (without replacement: just drop)
Header changes:
* `mlir-c/Registration.h` is deleted. Dialect registration functionality is now in `IR.h`. Registration of upstream features are in `mlir-c/RegisterEverything.h`. When updating MLIR and a couple of downstreams, I found that proper usage was commingled so required making a choice vs just blind S&R.
Python APIs removed:
* mlir.transforms and mlir.conversions (previously only had an __init__.py which indirectly triggered `mlirRegisterTransformsPasses()` and `mlirRegisterConversionPasses()` respectively). Downstream impact: Remove these imports if present (they now happen as part of default initialization).
* mlir._mlir_libs._all_passes_registration, mlir._mlir_libs._mlirTransforms, mlir._mlir_libs._mlirConversions. Downstream impact: None expected (these were internally used).
C-APIs changed:
* mlirRegisterAllDialects(MlirContext) now takes an MlirDialectRegistry instead. It also used to trigger loading of all dialects, which was already marked with a TODO to remove -- it no longer does, and for direct use, dialects must be explicitly loaded. Downstream impact: Direct C-API users must ensure that needed dialects are loaded or call `mlirContextLoadAllAvailableDialects(MlirContext)` to emulate the prior behavior. Also see the `ir.c` test case (e.g. ` mlirContextGetOrLoadDialect(ctx, mlirStringRefCreateFromCString("func"));`).
* mlirDialectHandle* APIs were moved from Registration.h (which now is restricted to just global/upstream registration) to IR.h, arguably where it should have been. Downstream impact: include correct header (likely already doing so).
C-APIs added:
* mlirContextLoadAllAvailableDialects(MlirContext): Corresponds to C++ API with the same purpose.
Python APIs added:
* mlir.ir.DialectRegistry: Mapping for an MlirDialectRegistry.
* mlir.ir.Context.append_dialect_registry(MlirDialectRegistry)
* mlir.ir.Context.load_all_available_dialects()
* mlir._mlir_libs._mlirAllRegistration: New native extension that exposes a `register_dialects(MlirDialectRegistry)` entry point and performs all upstream pass/conversion/transforms registration on init. In this first step, we eagerly load this as part of the __init__.py and use it to monkey patch the Context to emulate prior behavior.
* Type caster and capsule support for MlirDialectRegistry
This should make it possible to build downstream Python dialects that only depend on a subset of MLIR. See: https://github.com/llvm/llvm-project/issues/56037
Here is an example PR, minimally adapting IREE to these changes: https://github.com/iree-org/iree/pull/9638/files In this situation, IREE is opting to not link everything, since it is already configuring the Context to its liking. For projects that would just like to not think about it and pull in everything, add `MLIRPythonExtension.RegisterEverything` to the list of Python sources getting built, and the old behavior will continue.
Reviewed By: mehdi_amini, ftynse
Differential Revision: https://reviews.llvm.org/D128593
2022-07-16 16:09:03 -07:00
|
|
|
other.registry = {nullptr};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
operator MlirDialectRegistry() const { return registry; }
|
|
|
|
|
MlirDialectRegistry get() const { return registry; }
|
|
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
|
|
|
|
static PyDialectRegistry createFromCapsule(nanobind::object capsule);
|
[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.
Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functionality for dialects, extensions, etc. This was done pragmatically in order to get bootstrapped and then just grew in. Downstreams largely bypass and do their own thing by providing various APIs to register things they need. Meanwhile, the C++ APIs have stabilized around this and it would make sense to follow suit.
The thing we have observed in canonical usage by downstreams is that each downstream tends to have native entry points that configure its installation to its preferences with one-stop APIs. This patch leans in to this approach with `RegisterEverything.h` and `mlir._mlir_libs._mlirRegisterEverything` being the one-stop entry points for the "upstream packages". The `_mlir_libs.__init__.py` now allows customization of the environment and Context by adding "initialization modules" to the `_mlir_libs` package. If present, `_mlirRegisterEverything` is treated as such a module. Others can be added by downstreams by adding a `_site_initialize_{i}.py` module, where '{i}' is a number starting with zero. The number will be incremented and corresponding module loaded until one is not found. Initialization modules can:
* Perform load time customization to the global environment (i.e. registering passes, hooks, etc).
* Define a `register_dialects(registry: DialectRegistry)` function that can extend the `DialectRegistry` that will be used to bootstrap the `Context`.
* Define a `context_init_hook(context: Context)` function that will be added to a list of callbacks which will be invoked after dialect registration during `Context` initialization.
Note that the `MLIRPythonExtension.RegisterEverything` is not included by default when building a downstream (its corresponding behavior was prior). For downstreams which need the default MLIR initialization to take place, they must add this back in to their Python CMake build just like they add their own components (i.e. to `add_mlir_python_common_capi_library` and `add_mlir_python_modules`). It is perfectly valid to not do this, in which case, only the things explicitly depended on and initialized by downstreams will be built/packaged. If the downstream has not been set up for this, it is recommended to simply add this back for the time being and pay the build time/package size cost.
CMake changes:
* `MLIRCAPIRegistration` -> `MLIRCAPIRegisterEverything` (renamed to signify what it does and force an evaluation: a number of places were incidentally linking this very expensive target)
* `MLIRPythonSoure.Passes` removed (without replacement: just drop)
* `MLIRPythonExtension.AllPassesRegistration` removed (without replacement: just drop)
* `MLIRPythonExtension.Conversions` removed (without replacement: just drop)
* `MLIRPythonExtension.Transforms` removed (without replacement: just drop)
Header changes:
* `mlir-c/Registration.h` is deleted. Dialect registration functionality is now in `IR.h`. Registration of upstream features are in `mlir-c/RegisterEverything.h`. When updating MLIR and a couple of downstreams, I found that proper usage was commingled so required making a choice vs just blind S&R.
Python APIs removed:
* mlir.transforms and mlir.conversions (previously only had an __init__.py which indirectly triggered `mlirRegisterTransformsPasses()` and `mlirRegisterConversionPasses()` respectively). Downstream impact: Remove these imports if present (they now happen as part of default initialization).
* mlir._mlir_libs._all_passes_registration, mlir._mlir_libs._mlirTransforms, mlir._mlir_libs._mlirConversions. Downstream impact: None expected (these were internally used).
C-APIs changed:
* mlirRegisterAllDialects(MlirContext) now takes an MlirDialectRegistry instead. It also used to trigger loading of all dialects, which was already marked with a TODO to remove -- it no longer does, and for direct use, dialects must be explicitly loaded. Downstream impact: Direct C-API users must ensure that needed dialects are loaded or call `mlirContextLoadAllAvailableDialects(MlirContext)` to emulate the prior behavior. Also see the `ir.c` test case (e.g. ` mlirContextGetOrLoadDialect(ctx, mlirStringRefCreateFromCString("func"));`).
* mlirDialectHandle* APIs were moved from Registration.h (which now is restricted to just global/upstream registration) to IR.h, arguably where it should have been. Downstream impact: include correct header (likely already doing so).
C-APIs added:
* mlirContextLoadAllAvailableDialects(MlirContext): Corresponds to C++ API with the same purpose.
Python APIs added:
* mlir.ir.DialectRegistry: Mapping for an MlirDialectRegistry.
* mlir.ir.Context.append_dialect_registry(MlirDialectRegistry)
* mlir.ir.Context.load_all_available_dialects()
* mlir._mlir_libs._mlirAllRegistration: New native extension that exposes a `register_dialects(MlirDialectRegistry)` entry point and performs all upstream pass/conversion/transforms registration on init. In this first step, we eagerly load this as part of the __init__.py and use it to monkey patch the Context to emulate prior behavior.
* Type caster and capsule support for MlirDialectRegistry
This should make it possible to build downstream Python dialects that only depend on a subset of MLIR. See: https://github.com/llvm/llvm-project/issues/56037
Here is an example PR, minimally adapting IREE to these changes: https://github.com/iree-org/iree/pull/9638/files In this situation, IREE is opting to not link everything, since it is already configuring the Context to its liking. For projects that would just like to not think about it and pull in everything, add `MLIRPythonExtension.RegisterEverything` to the list of Python sources getting built, and the old behavior will continue.
Reviewed By: mehdi_amini, ftynse
Differential Revision: https://reviews.llvm.org/D128593
2022-07-16 16:09:03 -07:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirDialectRegistry registry;
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-31 23:40:25 -07:00
|
|
|
/// Used in function arguments when None should resolve to the current context
|
|
|
|
|
/// manager set instance.
|
|
|
|
|
class DefaultingPyLocation
|
|
|
|
|
: public Defaulting<DefaultingPyLocation, PyLocation> {
|
|
|
|
|
public:
|
|
|
|
|
using Defaulting::Defaulting;
|
2025-10-02 11:18:47 -04:00
|
|
|
static constexpr const char kTypeDescription[] = "Location";
|
2020-10-31 23:40:25 -07:00
|
|
|
static PyLocation &resolve();
|
2020-11-29 13:30:23 -08:00
|
|
|
|
|
|
|
|
operator MlirLocation() const { return *get(); }
|
2020-10-31 23:40:25 -07:00
|
|
|
};
|
|
|
|
|
|
2020-08-16 18:49:28 -07:00
|
|
|
/// Wrapper around MlirModule.
|
2020-09-18 18:38:21 -07:00
|
|
|
/// This is the top-level, user-owned object that contains regions/ops/blocks.
|
|
|
|
|
class PyModule;
|
|
|
|
|
using PyModuleRef = PyObjectRef<PyModule>;
|
2020-09-18 00:21:09 -07:00
|
|
|
class PyModule : public BaseContextObject {
|
2020-08-16 18:49:28 -07:00
|
|
|
public:
|
2025-09-01 21:53:33 -07:00
|
|
|
/// Returns a PyModule reference for the given MlirModule. This always returns
|
|
|
|
|
/// a new object.
|
2020-10-12 21:19:13 -07:00
|
|
|
static PyModuleRef forModule(MlirModule module);
|
2020-08-18 17:23:46 -07:00
|
|
|
PyModule(PyModule &) = delete;
|
2020-10-12 21:19:13 -07:00
|
|
|
PyModule(PyMlirContext &&) = delete;
|
|
|
|
|
~PyModule();
|
2020-08-16 18:49:28 -07:00
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
/// Gets the backing MlirModule.
|
|
|
|
|
MlirModule get() { return module; }
|
|
|
|
|
|
|
|
|
|
/// Gets a strong reference to this module.
|
|
|
|
|
PyModuleRef getRef() {
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
return PyModuleRef(this, nanobind::borrow<nanobind::object>(handle));
|
2020-09-18 18:38:21 -07:00
|
|
|
}
|
|
|
|
|
|
2020-09-28 09:08:09 -07:00
|
|
|
/// Gets a capsule wrapping the void* within the MlirModule.
|
|
|
|
|
/// Note that the module does not (yet) provide a corresponding factory for
|
|
|
|
|
/// constructing from a capsule as that would require uniquing PyModule
|
|
|
|
|
/// instances, which is not currently done.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2020-09-28 09:08:09 -07:00
|
|
|
|
2020-10-12 21:19:13 -07:00
|
|
|
/// Creates a PyModule from the MlirModule wrapped by a capsule.
|
2025-09-01 21:53:33 -07:00
|
|
|
/// Note this returns a new object BUT clearMlirModule() must be called to
|
|
|
|
|
/// prevent double-frees (of the underlying mlir::Module).
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object createFromCapsule(nanobind::object capsule);
|
2020-10-12 21:19:13 -07:00
|
|
|
|
2025-09-01 21:53:33 -07:00
|
|
|
void clearMlirModule() { module = {nullptr}; }
|
|
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
private:
|
2020-10-12 21:19:13 -07:00
|
|
|
PyModule(PyMlirContextRef contextRef, MlirModule module);
|
2020-08-16 18:49:28 -07:00
|
|
|
MlirModule module;
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::handle handle;
|
2020-09-18 18:38:21 -07:00
|
|
|
};
|
|
|
|
|
|
2023-11-13 10:21:21 -08:00
|
|
|
class PyAsmState;
|
|
|
|
|
|
2020-11-01 23:05:36 -08:00
|
|
|
/// Base class for PyOperation and PyOpView which exposes the primary, user
|
|
|
|
|
/// visible methods for manipulating it.
|
|
|
|
|
class PyOperationBase {
|
|
|
|
|
public:
|
|
|
|
|
virtual ~PyOperationBase() = default;
|
|
|
|
|
/// Implements the bound 'print' method and helps with others.
|
2025-07-17 12:57:04 -04:00
|
|
|
void print(std::optional<int64_t> largeElementsLimit,
|
|
|
|
|
std::optional<int64_t> largeResourceLimit, bool enableDebugInfo,
|
2021-11-28 15:33:03 -08:00
|
|
|
bool prettyDebugInfo, bool printGenericOpForm, bool useLocalScope,
|
2025-03-04 11:49:34 -08:00
|
|
|
bool useNameLocAsPrefix, bool assumeVerified,
|
|
|
|
|
nanobind::object fileObject, bool binary, bool skipRegions);
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
void print(PyAsmState &state, nanobind::object fileObject, bool binary);
|
2023-11-13 10:21:21 -08:00
|
|
|
|
2025-07-17 12:57:04 -04:00
|
|
|
nanobind::object
|
|
|
|
|
getAsm(bool binary, std::optional<int64_t> largeElementsLimit,
|
|
|
|
|
std::optional<int64_t> largeResourceLimit, bool enableDebugInfo,
|
|
|
|
|
bool prettyDebugInfo, bool printGenericOpForm, bool useLocalScope,
|
|
|
|
|
bool useNameLocAsPrefix, bool assumeVerified, bool skipRegions);
|
2020-11-01 23:05:36 -08:00
|
|
|
|
2022-09-05 11:54:19 +00:00
|
|
|
// Implement the bound 'writeBytecode' method.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
void writeBytecode(const nanobind::object &fileObject,
|
2023-04-30 22:11:02 -07:00
|
|
|
std::optional<int64_t> bytecodeVersion);
|
2022-09-05 11:54:19 +00:00
|
|
|
|
2024-04-17 15:09:47 +09:00
|
|
|
// Implement the walk method.
|
|
|
|
|
void walk(std::function<MlirWalkResult(MlirOperation)> callback,
|
|
|
|
|
MlirWalkOrder walkOrder);
|
|
|
|
|
|
2021-10-31 09:37:20 +01:00
|
|
|
/// Moves the operation before or after the other operation.
|
|
|
|
|
void moveAfter(PyOperationBase &other);
|
|
|
|
|
void moveBefore(PyOperationBase &other);
|
|
|
|
|
|
2025-07-23 12:33:42 -05:00
|
|
|
/// Given an operation 'other' that is within the same parent block, return
|
|
|
|
|
/// whether the current operation is before 'other' in the operation list
|
|
|
|
|
/// of the parent block.
|
|
|
|
|
/// Note: This function has an average complexity of O(1), but worst case may
|
|
|
|
|
/// take O(N) where N is the number of operations within the parent block.
|
|
|
|
|
bool isBeforeInBlock(PyOperationBase &other);
|
|
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
/// Verify the operation. Throws `MLIRError` if verification fails, and
|
|
|
|
|
/// returns `true` otherwise.
|
|
|
|
|
bool verify();
|
|
|
|
|
|
2020-11-01 23:05:36 -08:00
|
|
|
/// Each must provide access to the raw Operation.
|
|
|
|
|
virtual PyOperation &getOperation() = 0;
|
|
|
|
|
};
|
|
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
/// Wrapper around PyOperation.
|
|
|
|
|
/// Operations exist in either an attached (dependent) or detached (top-level)
|
|
|
|
|
/// state. In the detached state (as on creation), an operation is owned by
|
|
|
|
|
/// the creator and its lifetime extends either until its reference count
|
|
|
|
|
/// drops to zero or it is attached to a parent, at which point its lifetime
|
|
|
|
|
/// is bounded by its top-level parent reference.
|
|
|
|
|
class PyOperation;
|
2025-09-20 14:47:32 -04:00
|
|
|
class PyOpView;
|
2020-09-18 18:38:21 -07:00
|
|
|
using PyOperationRef = PyObjectRef<PyOperation>;
|
2020-11-01 23:05:36 -08:00
|
|
|
class PyOperation : public PyOperationBase, public BaseContextObject {
|
2020-09-18 18:38:21 -07:00
|
|
|
public:
|
2022-01-14 01:35:38 +00:00
|
|
|
~PyOperation() override;
|
2020-11-01 23:05:36 -08:00
|
|
|
PyOperation &getOperation() override { return *this; }
|
|
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
/// Returns a PyOperation for the given MlirOperation, optionally associating
|
2020-10-28 23:16:36 -07:00
|
|
|
/// it with a parentKeepAlive.
|
2020-09-18 18:38:21 -07:00
|
|
|
static PyOperationRef
|
|
|
|
|
forOperation(PyMlirContextRef contextRef, MlirOperation operation,
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object parentKeepAlive = nanobind::object());
|
2020-09-18 18:38:21 -07:00
|
|
|
|
|
|
|
|
/// Creates a detached operation. The operation must not be associated with
|
|
|
|
|
/// any existing live operation.
|
|
|
|
|
static PyOperationRef
|
|
|
|
|
createDetached(PyMlirContextRef contextRef, MlirOperation operation,
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object parentKeepAlive = nanobind::object());
|
2020-09-18 18:38:21 -07:00
|
|
|
|
2022-11-08 16:55:06 -05:00
|
|
|
/// Parses a source string (either text assembly or bytecode), creating a
|
|
|
|
|
/// detached operation.
|
|
|
|
|
static PyOperationRef parse(PyMlirContextRef contextRef,
|
|
|
|
|
const std::string &sourceStr,
|
|
|
|
|
const std::string &sourceName);
|
|
|
|
|
|
2021-10-31 09:37:20 +01:00
|
|
|
/// Detaches the operation from its parent block and updates its state
|
|
|
|
|
/// accordingly.
|
|
|
|
|
void detachFromParent() {
|
|
|
|
|
mlirOperationRemoveFromParent(getOperation());
|
|
|
|
|
setDetached();
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
parentKeepAlive = nanobind::object();
|
2021-10-31 09:37:20 +01:00
|
|
|
}
|
|
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
/// Gets the backing operation.
|
2020-11-29 13:52:11 -08:00
|
|
|
operator MlirOperation() const { return get(); }
|
|
|
|
|
MlirOperation get() const {
|
2020-09-18 18:38:21 -07:00
|
|
|
checkValid();
|
|
|
|
|
return operation;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PyOperationRef getRef() {
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
return PyOperationRef(this, nanobind::borrow<nanobind::object>(handle));
|
2020-09-18 18:38:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool isAttached() { return attached; }
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
void setAttached(const nanobind::object &parent = nanobind::object()) {
|
2020-09-20 21:25:46 -07:00
|
|
|
assert(!attached && "operation already attached");
|
|
|
|
|
attached = true;
|
|
|
|
|
}
|
2021-10-31 09:37:20 +01:00
|
|
|
void setDetached() {
|
|
|
|
|
assert(attached && "operation already detached");
|
|
|
|
|
attached = false;
|
|
|
|
|
}
|
2020-11-29 13:52:11 -08:00
|
|
|
void checkValid() const;
|
2020-09-18 18:38:21 -07:00
|
|
|
|
2020-10-28 23:16:36 -07:00
|
|
|
/// Gets the owning block or raises an exception if the operation has no
|
|
|
|
|
/// owning block.
|
|
|
|
|
PyBlock getBlock();
|
|
|
|
|
|
|
|
|
|
/// Gets the parent operation or raises an exception if the operation has
|
|
|
|
|
/// no parent.
|
2023-01-14 01:25:58 -08:00
|
|
|
std::optional<PyOperationRef> getParentOperation();
|
2020-10-28 23:16:36 -07:00
|
|
|
|
2021-04-06 14:15:22 -07:00
|
|
|
/// Gets a capsule wrapping the void* within the MlirOperation.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2021-04-06 14:15:22 -07:00
|
|
|
|
|
|
|
|
/// Creates a PyOperation from the MlirOperation wrapped by a capsule.
|
|
|
|
|
/// Ownership of the underlying MlirOperation is taken by calling this
|
|
|
|
|
/// function.
|
2025-09-23 13:54:22 -04:00
|
|
|
static nanobind::object createFromCapsule(const nanobind::object &capsule);
|
2021-04-06 14:15:22 -07:00
|
|
|
|
2020-10-31 23:40:25 -07:00
|
|
|
/// Creates an operation. See corresponding python docstring.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object
|
[mlir python] Change PyOpView constructor to construct operations. (#123777)
Previously ODS-generated Python operations had code like this:
```
super().__init__(self.build_generic(attributes=attributes, operands=operands, successors=_ods_successors, regions=regions, loc=loc, ip=ip))
```
we change it to:
```
super().__init__(self.OPERATION_NAME, self._ODS_REGIONS, self._ODS_OPERAND_SEGMENTS, self._ODS_RESULT_SEGMENTS, attributes=attributes, operands=operands, successors=_ods_successors, regions=regions, loc=loc, ip=ip)
```
This:
a) avoids an extra call dispatch (to `build_generic`), and
b) passes the class attributes directly to the constructor. Benchmarks
show that it is faster to pass these as arguments rather than having the
C++ code look up attributes on the class.
This PR improves the timing of the following benchmark on my workstation
from 5.3s to 4.5s:
```
def main(_):
with ir.Context(), ir.Location.unknown():
typ = ir.IntegerType.get_signless(32)
m = ir.Module.create()
with ir.InsertionPoint(m.body):
start = time.time()
for i in range(1000000):
arith.ConstantOp(typ, i)
end = time.time()
print(f"time: {end - start}")
```
Since this change adds an additional overload to the constructor and
does not alter any existing behaviors, it should be backwards
compatible.
2025-01-22 09:21:46 -05:00
|
|
|
create(std::string_view name, std::optional<std::vector<PyType *>> results,
|
2025-01-24 09:26:28 -05:00
|
|
|
llvm::ArrayRef<MlirValue> operands,
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
std::optional<nanobind::dict> attributes,
|
2023-01-14 01:25:58 -08:00
|
|
|
std::optional<std::vector<PyBlock *>> successors, int regions,
|
2025-08-12 17:59:59 -04:00
|
|
|
PyLocation &location, const nanobind::object &ip, bool inferType);
|
2020-10-31 23:40:25 -07:00
|
|
|
|
2020-11-01 23:05:36 -08:00
|
|
|
/// Creates an OpView suitable for this operation.
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object createOpView();
|
2020-11-01 23:05:36 -08:00
|
|
|
|
2021-04-23 20:54:04 -06:00
|
|
|
/// Erases the underlying MlirOperation, removes its pointer from the
|
|
|
|
|
/// parent context's live operations map, and sets the valid bit false.
|
|
|
|
|
void erase();
|
|
|
|
|
|
2022-04-19 15:03:15 -07:00
|
|
|
/// Invalidate the operation.
|
|
|
|
|
void setInvalid() { valid = false; }
|
|
|
|
|
|
2022-03-28 15:45:40 +02:00
|
|
|
/// Clones this operation.
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object clone(const nanobind::object &ip);
|
2022-03-28 15:45:40 +02:00
|
|
|
|
2020-09-18 18:38:21 -07:00
|
|
|
PyOperation(PyMlirContextRef contextRef, MlirOperation operation);
|
2025-01-22 09:26:44 -05:00
|
|
|
|
|
|
|
|
private:
|
2020-09-18 18:38:21 -07:00
|
|
|
static PyOperationRef createInstance(PyMlirContextRef contextRef,
|
|
|
|
|
MlirOperation operation,
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object parentKeepAlive);
|
2020-09-18 18:38:21 -07:00
|
|
|
|
|
|
|
|
MlirOperation operation;
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::handle handle;
|
2020-09-18 18:38:21 -07:00
|
|
|
// Keeps the parent alive, regardless of whether it is an Operation or
|
|
|
|
|
// Module.
|
|
|
|
|
// TODO: As implemented, this facility is only sufficient for modeling the
|
|
|
|
|
// trivial module parent back-reference. Generalize this to also account for
|
|
|
|
|
// transitions from detached to attached and address TODOs in the
|
|
|
|
|
// ir_operation.py regarding testing corresponding lifetime guarantees.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object parentKeepAlive;
|
2020-09-18 18:38:21 -07:00
|
|
|
bool attached = true;
|
|
|
|
|
bool valid = true;
|
2021-10-31 09:37:20 +01:00
|
|
|
|
|
|
|
|
friend class PyOperationBase;
|
2021-11-02 12:39:36 +01:00
|
|
|
friend class PySymbolTable;
|
2020-08-16 18:49:28 -07:00
|
|
|
};
|
|
|
|
|
|
2020-10-21 23:34:01 -07:00
|
|
|
/// A PyOpView is equivalent to the C++ "Op" wrappers: these are the basis for
|
|
|
|
|
/// providing more instance-specific accessors and serve as the base class for
|
|
|
|
|
/// custom ODS-style operation classes. Since this class is subclass on the
|
|
|
|
|
/// python side, it must present an __init__ method that operates in pure
|
|
|
|
|
/// python types.
|
2020-11-01 23:05:36 -08:00
|
|
|
class PyOpView : public PyOperationBase {
|
2020-10-21 23:34:01 -07:00
|
|
|
public:
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
PyOpView(const nanobind::object &operationObject);
|
2020-11-01 23:05:36 -08:00
|
|
|
PyOperation &getOperation() override { return operation; }
|
2020-10-21 23:34:01 -07:00
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getOperationObject() { return operationObject; }
|
2020-10-21 23:34:01 -07:00
|
|
|
|
[mlir python] Change PyOpView constructor to construct operations. (#123777)
Previously ODS-generated Python operations had code like this:
```
super().__init__(self.build_generic(attributes=attributes, operands=operands, successors=_ods_successors, regions=regions, loc=loc, ip=ip))
```
we change it to:
```
super().__init__(self.OPERATION_NAME, self._ODS_REGIONS, self._ODS_OPERAND_SEGMENTS, self._ODS_RESULT_SEGMENTS, attributes=attributes, operands=operands, successors=_ods_successors, regions=regions, loc=loc, ip=ip)
```
This:
a) avoids an extra call dispatch (to `build_generic`), and
b) passes the class attributes directly to the constructor. Benchmarks
show that it is faster to pass these as arguments rather than having the
C++ code look up attributes on the class.
This PR improves the timing of the following benchmark on my workstation
from 5.3s to 4.5s:
```
def main(_):
with ir.Context(), ir.Location.unknown():
typ = ir.IntegerType.get_signless(32)
m = ir.Module.create()
with ir.InsertionPoint(m.body):
start = time.time()
for i in range(1000000):
arith.ConstantOp(typ, i)
end = time.time()
print(f"time: {end - start}")
```
Since this change adds an additional overload to the constructor and
does not alter any existing behaviors, it should be backwards
compatible.
2025-01-22 09:21:46 -05:00
|
|
|
static nanobind::object
|
|
|
|
|
buildGeneric(std::string_view name, std::tuple<int, bool> opRegionSpec,
|
|
|
|
|
nanobind::object operandSegmentSpecObj,
|
|
|
|
|
nanobind::object resultSegmentSpecObj,
|
|
|
|
|
std::optional<nanobind::list> resultTypeList,
|
|
|
|
|
nanobind::list operandList,
|
|
|
|
|
std::optional<nanobind::dict> attributes,
|
|
|
|
|
std::optional<std::vector<PyBlock *>> successors,
|
2025-08-12 17:59:59 -04:00
|
|
|
std::optional<int> regions, PyLocation &location,
|
[mlir python] Change PyOpView constructor to construct operations. (#123777)
Previously ODS-generated Python operations had code like this:
```
super().__init__(self.build_generic(attributes=attributes, operands=operands, successors=_ods_successors, regions=regions, loc=loc, ip=ip))
```
we change it to:
```
super().__init__(self.OPERATION_NAME, self._ODS_REGIONS, self._ODS_OPERAND_SEGMENTS, self._ODS_RESULT_SEGMENTS, attributes=attributes, operands=operands, successors=_ods_successors, regions=regions, loc=loc, ip=ip)
```
This:
a) avoids an extra call dispatch (to `build_generic`), and
b) passes the class attributes directly to the constructor. Benchmarks
show that it is faster to pass these as arguments rather than having the
C++ code look up attributes on the class.
This PR improves the timing of the following benchmark on my workstation
from 5.3s to 4.5s:
```
def main(_):
with ir.Context(), ir.Location.unknown():
typ = ir.IntegerType.get_signless(32)
m = ir.Module.create()
with ir.InsertionPoint(m.body):
start = time.time()
for i in range(1000000):
arith.ConstantOp(typ, i)
end = time.time()
print(f"time: {end - start}")
```
Since this change adds an additional overload to the constructor and
does not alter any existing behaviors, it should be backwards
compatible.
2025-01-22 09:21:46 -05:00
|
|
|
const nanobind::object &maybeIp);
|
2021-01-18 11:27:19 -08:00
|
|
|
|
2023-01-22 23:31:18 -05:00
|
|
|
/// Construct an instance of a class deriving from OpView, bypassing its
|
|
|
|
|
/// `__init__` method. The derived class will typically define a constructor
|
|
|
|
|
/// that provides a convenient builder, but we need to side-step this when
|
|
|
|
|
/// constructing an `OpView` for an already-built operation.
|
|
|
|
|
///
|
|
|
|
|
/// The caller is responsible for verifying that `operation` is a valid
|
|
|
|
|
/// operation to construct `cls` with.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object constructDerived(const nanobind::object &cls,
|
|
|
|
|
const nanobind::object &operation);
|
2023-01-22 23:31:18 -05:00
|
|
|
|
2020-10-21 23:34:01 -07:00
|
|
|
private:
|
2020-11-01 23:05:36 -08:00
|
|
|
PyOperation &operation; // For efficient, cast-free access from C++
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object operationObject; // Holds the reference.
|
2020-10-21 23:34:01 -07:00
|
|
|
};
|
|
|
|
|
|
2020-08-26 23:48:42 -07:00
|
|
|
/// Wrapper around an MlirRegion.
|
2020-09-19 22:02:32 -07:00
|
|
|
/// Regions are managed completely by their containing operation. Unlike the
|
|
|
|
|
/// C++ API, the python API does not support detached regions.
|
2020-08-26 23:48:42 -07:00
|
|
|
class PyRegion {
|
|
|
|
|
public:
|
2020-09-19 22:02:32 -07:00
|
|
|
PyRegion(PyOperationRef parentOperation, MlirRegion region)
|
|
|
|
|
: parentOperation(std::move(parentOperation)), region(region) {
|
|
|
|
|
assert(!mlirRegionIsNull(region) && "python region cannot be null");
|
2020-08-26 23:48:42 -07:00
|
|
|
}
|
2021-10-11 18:24:48 +02:00
|
|
|
operator MlirRegion() const { return region; }
|
2020-08-26 23:48:42 -07:00
|
|
|
|
2020-09-19 22:02:32 -07:00
|
|
|
MlirRegion get() { return region; }
|
|
|
|
|
PyOperationRef &getParentOperation() { return parentOperation; }
|
2020-08-26 23:48:42 -07:00
|
|
|
|
2020-09-19 22:02:32 -07:00
|
|
|
void checkValid() { return parentOperation->checkValid(); }
|
2020-08-26 23:48:42 -07:00
|
|
|
|
|
|
|
|
private:
|
2020-09-19 22:02:32 -07:00
|
|
|
PyOperationRef parentOperation;
|
|
|
|
|
MlirRegion region;
|
2020-08-26 23:48:42 -07:00
|
|
|
};
|
|
|
|
|
|
2023-09-20 15:12:06 -07:00
|
|
|
/// Wrapper around an MlirAsmState.
|
|
|
|
|
class PyAsmState {
|
[mlir][python] value casting (#69644)
This PR adds "value casting", i.e., a mechanism to wrap `ir.Value` in a
proxy class that overloads dunders such as `__add__`, `__sub__`, and
`__mul__` for fun and great profit.
This is thematically similar to
https://github.com/llvm/llvm-project/commit/bfb1ba752655bf09b35c486f6cc9817dbedfb1bb
and
https://github.com/llvm/llvm-project/commit/9566ee280607d91fa2e5eca730a6765ac84dfd0f.
The example in the test demonstrates the value of the feature (no pun
intended):
```python
@register_value_caster(F16Type.static_typeid)
@register_value_caster(F32Type.static_typeid)
@register_value_caster(F64Type.static_typeid)
@register_value_caster(IntegerType.static_typeid)
class ArithValue(Value):
__add__ = partialmethod(_binary_op, op="add")
__sub__ = partialmethod(_binary_op, op="sub")
__mul__ = partialmethod(_binary_op, op="mul")
a = arith.constant(value=FloatAttr.get(f16_t, 42.42))
b = a + a
# CHECK: ArithValue(%0 = arith.addf %cst, %cst : f16)
print(b)
a = arith.constant(value=FloatAttr.get(f32_t, 42.42))
b = a - a
# CHECK: ArithValue(%1 = arith.subf %cst_0, %cst_0 : f32)
print(b)
a = arith.constant(value=FloatAttr.get(f64_t, 42.42))
b = a * a
# CHECK: ArithValue(%2 = arith.mulf %cst_1, %cst_1 : f64)
print(b)
```
**EDIT**: this now goes through the bindings and thus supports automatic
casting of `OpResult` (including as an element of `OpResultList`),
`BlockArgument` (including as an element of `BlockArgumentList`), as
well as `Value`.
2023-11-07 10:49:41 -06:00
|
|
|
public:
|
2023-09-20 15:12:06 -07:00
|
|
|
PyAsmState(MlirValue value, bool useLocalScope) {
|
|
|
|
|
flags = mlirOpPrintingFlagsCreate();
|
|
|
|
|
// The OpPrintingFlags are not exposed Python side, create locally and
|
|
|
|
|
// associate lifetime with the state.
|
|
|
|
|
if (useLocalScope)
|
|
|
|
|
mlirOpPrintingFlagsUseLocalScope(flags);
|
|
|
|
|
state = mlirAsmStateCreateForValue(value, flags);
|
|
|
|
|
}
|
2023-09-25 12:25:08 -07:00
|
|
|
|
|
|
|
|
PyAsmState(PyOperationBase &operation, bool useLocalScope) {
|
|
|
|
|
flags = mlirOpPrintingFlagsCreate();
|
|
|
|
|
// The OpPrintingFlags are not exposed Python side, create locally and
|
|
|
|
|
// associate lifetime with the state.
|
|
|
|
|
if (useLocalScope)
|
|
|
|
|
mlirOpPrintingFlagsUseLocalScope(flags);
|
|
|
|
|
state =
|
|
|
|
|
mlirAsmStateCreateForOperation(operation.getOperation().get(), flags);
|
|
|
|
|
}
|
[mlir][python] value casting (#69644)
This PR adds "value casting", i.e., a mechanism to wrap `ir.Value` in a
proxy class that overloads dunders such as `__add__`, `__sub__`, and
`__mul__` for fun and great profit.
This is thematically similar to
https://github.com/llvm/llvm-project/commit/bfb1ba752655bf09b35c486f6cc9817dbedfb1bb
and
https://github.com/llvm/llvm-project/commit/9566ee280607d91fa2e5eca730a6765ac84dfd0f.
The example in the test demonstrates the value of the feature (no pun
intended):
```python
@register_value_caster(F16Type.static_typeid)
@register_value_caster(F32Type.static_typeid)
@register_value_caster(F64Type.static_typeid)
@register_value_caster(IntegerType.static_typeid)
class ArithValue(Value):
__add__ = partialmethod(_binary_op, op="add")
__sub__ = partialmethod(_binary_op, op="sub")
__mul__ = partialmethod(_binary_op, op="mul")
a = arith.constant(value=FloatAttr.get(f16_t, 42.42))
b = a + a
# CHECK: ArithValue(%0 = arith.addf %cst, %cst : f16)
print(b)
a = arith.constant(value=FloatAttr.get(f32_t, 42.42))
b = a - a
# CHECK: ArithValue(%1 = arith.subf %cst_0, %cst_0 : f32)
print(b)
a = arith.constant(value=FloatAttr.get(f64_t, 42.42))
b = a * a
# CHECK: ArithValue(%2 = arith.mulf %cst_1, %cst_1 : f64)
print(b)
```
**EDIT**: this now goes through the bindings and thus supports automatic
casting of `OpResult` (including as an element of `OpResultList`),
`BlockArgument` (including as an element of `BlockArgumentList`), as
well as `Value`.
2023-11-07 10:49:41 -06:00
|
|
|
~PyAsmState() { mlirOpPrintingFlagsDestroy(flags); }
|
2023-09-20 15:12:06 -07:00
|
|
|
// Delete copy constructors.
|
|
|
|
|
PyAsmState(PyAsmState &other) = delete;
|
|
|
|
|
PyAsmState(const PyAsmState &other) = delete;
|
|
|
|
|
|
|
|
|
|
MlirAsmState get() { return state; }
|
|
|
|
|
|
[mlir][python] value casting (#69644)
This PR adds "value casting", i.e., a mechanism to wrap `ir.Value` in a
proxy class that overloads dunders such as `__add__`, `__sub__`, and
`__mul__` for fun and great profit.
This is thematically similar to
https://github.com/llvm/llvm-project/commit/bfb1ba752655bf09b35c486f6cc9817dbedfb1bb
and
https://github.com/llvm/llvm-project/commit/9566ee280607d91fa2e5eca730a6765ac84dfd0f.
The example in the test demonstrates the value of the feature (no pun
intended):
```python
@register_value_caster(F16Type.static_typeid)
@register_value_caster(F32Type.static_typeid)
@register_value_caster(F64Type.static_typeid)
@register_value_caster(IntegerType.static_typeid)
class ArithValue(Value):
__add__ = partialmethod(_binary_op, op="add")
__sub__ = partialmethod(_binary_op, op="sub")
__mul__ = partialmethod(_binary_op, op="mul")
a = arith.constant(value=FloatAttr.get(f16_t, 42.42))
b = a + a
# CHECK: ArithValue(%0 = arith.addf %cst, %cst : f16)
print(b)
a = arith.constant(value=FloatAttr.get(f32_t, 42.42))
b = a - a
# CHECK: ArithValue(%1 = arith.subf %cst_0, %cst_0 : f32)
print(b)
a = arith.constant(value=FloatAttr.get(f64_t, 42.42))
b = a * a
# CHECK: ArithValue(%2 = arith.mulf %cst_1, %cst_1 : f64)
print(b)
```
**EDIT**: this now goes through the bindings and thus supports automatic
casting of `OpResult` (including as an element of `OpResultList`),
`BlockArgument` (including as an element of `BlockArgumentList`), as
well as `Value`.
2023-11-07 10:49:41 -06:00
|
|
|
private:
|
2023-09-20 15:12:06 -07:00
|
|
|
MlirAsmState state;
|
|
|
|
|
MlirOpPrintingFlags flags;
|
|
|
|
|
};
|
|
|
|
|
|
2020-08-26 23:48:42 -07:00
|
|
|
/// Wrapper around an MlirBlock.
|
2020-09-19 22:02:32 -07:00
|
|
|
/// Blocks are managed completely by their containing operation. Unlike the
|
|
|
|
|
/// C++ API, the python API does not support detached blocks.
|
2020-08-26 23:48:42 -07:00
|
|
|
class PyBlock {
|
|
|
|
|
public:
|
2020-09-19 22:02:32 -07:00
|
|
|
PyBlock(PyOperationRef parentOperation, MlirBlock block)
|
|
|
|
|
: parentOperation(std::move(parentOperation)), block(block) {
|
|
|
|
|
assert(!mlirBlockIsNull(block) && "python block cannot be null");
|
2020-08-26 23:48:42 -07:00
|
|
|
}
|
|
|
|
|
|
2020-09-19 22:02:32 -07:00
|
|
|
MlirBlock get() { return block; }
|
|
|
|
|
PyOperationRef &getParentOperation() { return parentOperation; }
|
2020-08-26 23:48:42 -07:00
|
|
|
|
2020-09-19 22:02:32 -07:00
|
|
|
void checkValid() { return parentOperation->checkValid(); }
|
2020-08-26 23:48:42 -07:00
|
|
|
|
2023-07-12 22:11:14 -07:00
|
|
|
/// Gets a capsule wrapping the void* within the MlirBlock.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2023-07-12 22:11:14 -07:00
|
|
|
|
2020-08-26 23:48:42 -07:00
|
|
|
private:
|
2020-09-19 22:02:32 -07:00
|
|
|
PyOperationRef parentOperation;
|
|
|
|
|
MlirBlock block;
|
2020-08-26 23:48:42 -07:00
|
|
|
};
|
|
|
|
|
|
2020-10-28 23:16:36 -07:00
|
|
|
/// An insertion point maintains a pointer to a Block and a reference operation.
|
|
|
|
|
/// Calls to insert() will insert a new operation before the
|
|
|
|
|
/// reference operation. If the reference operation is null, then appends to
|
|
|
|
|
/// the end of the block.
|
|
|
|
|
class PyInsertionPoint {
|
|
|
|
|
public:
|
|
|
|
|
/// Creates an insertion point positioned after the last operation in the
|
|
|
|
|
/// block, but still inside the block.
|
2025-09-05 14:30:40 -07:00
|
|
|
PyInsertionPoint(const PyBlock &block);
|
2020-10-28 23:16:36 -07:00
|
|
|
/// Creates an insertion point positioned before a reference operation.
|
2020-11-01 23:05:36 -08:00
|
|
|
PyInsertionPoint(PyOperationBase &beforeOperationBase);
|
2025-10-05 11:12:11 +08:00
|
|
|
/// Creates an insertion point positioned before a reference operation.
|
|
|
|
|
PyInsertionPoint(PyOperationRef beforeOperationRef);
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Shortcut to create an insertion point at the beginning of the block.
|
|
|
|
|
static PyInsertionPoint atBlockBegin(PyBlock &block);
|
|
|
|
|
/// Shortcut to create an insertion point before the block terminator.
|
|
|
|
|
static PyInsertionPoint atBlockTerminator(PyBlock &block);
|
2025-09-05 14:30:40 -07:00
|
|
|
/// Shortcut to create an insertion point to the node after the specified
|
|
|
|
|
/// operation.
|
|
|
|
|
static PyInsertionPoint after(PyOperationBase &op);
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Inserts an operation.
|
2020-11-01 23:05:36 -08:00
|
|
|
void insert(PyOperationBase &operationBase);
|
2020-10-28 23:16:36 -07:00
|
|
|
|
|
|
|
|
/// Enter and exit the context manager.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static nanobind::object contextEnter(nanobind::object insertionPoint);
|
|
|
|
|
void contextExit(const nanobind::object &excType,
|
|
|
|
|
const nanobind::object &excVal,
|
|
|
|
|
const nanobind::object &excTb);
|
2020-10-28 23:16:36 -07:00
|
|
|
|
2020-10-31 23:40:25 -07:00
|
|
|
PyBlock &getBlock() { return block; }
|
2023-10-18 16:53:18 +02:00
|
|
|
std::optional<PyOperationRef> &getRefOperation() { return refOperation; }
|
2020-10-31 23:40:25 -07:00
|
|
|
|
2020-10-28 23:16:36 -07:00
|
|
|
private:
|
|
|
|
|
// Trampoline constructor that avoids null initializing members while
|
|
|
|
|
// looking up parents.
|
2023-01-14 01:25:58 -08:00
|
|
|
PyInsertionPoint(PyBlock block, std::optional<PyOperationRef> refOperation)
|
2020-11-01 23:05:36 -08:00
|
|
|
: refOperation(std::move(refOperation)), block(std::move(block)) {}
|
2020-10-28 23:16:36 -07:00
|
|
|
|
2023-01-14 01:25:58 -08:00
|
|
|
std::optional<PyOperationRef> refOperation;
|
2020-11-01 23:05:36 -08:00
|
|
|
PyBlock block;
|
2020-10-28 23:16:36 -07:00
|
|
|
};
|
2021-10-14 17:19:06 +02:00
|
|
|
/// Wrapper around the generic MlirType.
|
|
|
|
|
/// The lifetime of a type is bound by the PyContext that created it.
|
|
|
|
|
class PyType : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyType(PyMlirContextRef contextRef, MlirType type)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), type(type) {}
|
2023-03-28 11:05:00 -04:00
|
|
|
bool operator==(const PyType &other) const;
|
2021-10-14 17:19:06 +02:00
|
|
|
operator MlirType() const { return type; }
|
|
|
|
|
MlirType get() const { return type; }
|
|
|
|
|
|
|
|
|
|
/// Gets a capsule wrapping the void* within the MlirType.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2021-10-14 17:19:06 +02:00
|
|
|
|
|
|
|
|
/// Creates a PyType from the MlirType wrapped by a capsule.
|
|
|
|
|
/// Note that PyType instances are uniqued, so the returned object
|
|
|
|
|
/// may be a pre-existing object. Ownership of the underlying MlirType
|
|
|
|
|
/// is taken by calling this function.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static PyType createFromCapsule(nanobind::object capsule);
|
2021-10-14 17:19:06 +02:00
|
|
|
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object maybeDownCast();
|
2025-09-20 14:47:32 -04:00
|
|
|
|
2021-10-14 17:19:06 +02:00
|
|
|
private:
|
|
|
|
|
MlirType type;
|
|
|
|
|
};
|
|
|
|
|
|
2023-05-22 11:12:53 -05:00
|
|
|
/// A TypeID provides an efficient and unique identifier for a specific C++
|
|
|
|
|
/// type. This allows for a C++ type to be compared, hashed, and stored in an
|
|
|
|
|
/// opaque context. This class wraps around the generic MlirTypeID.
|
|
|
|
|
class PyTypeID {
|
|
|
|
|
public:
|
|
|
|
|
PyTypeID(MlirTypeID typeID) : typeID(typeID) {}
|
|
|
|
|
// Note, this tests whether the underlying TypeIDs are the same,
|
|
|
|
|
// not whether the wrapper MlirTypeIDs are the same, nor whether
|
|
|
|
|
// the PyTypeID objects are the same (i.e., PyTypeID is a value type).
|
|
|
|
|
bool operator==(const PyTypeID &other) const;
|
|
|
|
|
operator MlirTypeID() const { return typeID; }
|
|
|
|
|
MlirTypeID get() { return typeID; }
|
|
|
|
|
|
|
|
|
|
/// Gets a capsule wrapping the void* within the MlirTypeID.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2023-05-22 11:12:53 -05:00
|
|
|
|
|
|
|
|
/// Creates a PyTypeID from the MlirTypeID wrapped by a capsule.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static PyTypeID createFromCapsule(nanobind::object capsule);
|
2023-05-22 11:12:53 -05:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirTypeID typeID;
|
|
|
|
|
};
|
|
|
|
|
|
2021-10-14 17:19:06 +02:00
|
|
|
/// CRTP base classes for Python types that subclass Type and should be
|
|
|
|
|
/// castable from it (i.e. via something like IntegerType(t)).
|
|
|
|
|
/// By default, type class hierarchies are one level deep (i.e. a
|
|
|
|
|
/// concrete type class extends PyType); however, intermediate python-visible
|
|
|
|
|
/// base classes can be modeled by specifying a BaseTy.
|
|
|
|
|
template <typename DerivedTy, typename BaseTy = PyType>
|
|
|
|
|
class PyConcreteType : public BaseTy {
|
|
|
|
|
public:
|
|
|
|
|
// Derived classes must define statics for:
|
|
|
|
|
// IsAFunctionTy isaFunction
|
|
|
|
|
// const char *pyClassName
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
using ClassTy = nanobind::class_<DerivedTy, BaseTy>;
|
2021-10-14 17:19:06 +02:00
|
|
|
using IsAFunctionTy = bool (*)(MlirType);
|
2023-05-22 11:12:53 -05:00
|
|
|
using GetTypeIDFunctionTy = MlirTypeID (*)();
|
|
|
|
|
static constexpr GetTypeIDFunctionTy getTypeIdFunction = nullptr;
|
2021-10-14 17:19:06 +02:00
|
|
|
|
|
|
|
|
PyConcreteType() = default;
|
|
|
|
|
PyConcreteType(PyMlirContextRef contextRef, MlirType t)
|
2023-05-26 10:23:17 -05:00
|
|
|
: BaseTy(std::move(contextRef), t) {}
|
2021-10-14 17:19:06 +02:00
|
|
|
PyConcreteType(PyType &orig)
|
|
|
|
|
: PyConcreteType(orig.getContext(), castFrom(orig)) {}
|
|
|
|
|
|
|
|
|
|
static MlirType castFrom(PyType &orig) {
|
|
|
|
|
if (!DerivedTy::isaFunction(orig)) {
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
auto origRepr =
|
|
|
|
|
nanobind::cast<std::string>(nanobind::repr(nanobind::cast(orig)));
|
|
|
|
|
throw nanobind::value_error((llvm::Twine("Cannot cast type to ") +
|
|
|
|
|
DerivedTy::pyClassName + " (from " +
|
|
|
|
|
origRepr + ")")
|
|
|
|
|
.str()
|
|
|
|
|
.c_str());
|
2021-10-14 17:19:06 +02:00
|
|
|
}
|
|
|
|
|
return orig;
|
|
|
|
|
}
|
|
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static void bind(nanobind::module_ &m) {
|
|
|
|
|
auto cls = ClassTy(m, DerivedTy::pyClassName);
|
|
|
|
|
cls.def(nanobind::init<PyType &>(), nanobind::keep_alive<0, 1>(),
|
|
|
|
|
nanobind::arg("cast_from_type"));
|
2021-11-28 14:08:06 -08:00
|
|
|
cls.def_static(
|
|
|
|
|
"isinstance",
|
|
|
|
|
[](PyType &otherType) -> bool {
|
|
|
|
|
return DerivedTy::isaFunction(otherType);
|
|
|
|
|
},
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::arg("other"));
|
|
|
|
|
cls.def_prop_ro_static(
|
2025-09-20 14:47:32 -04:00
|
|
|
"static_typeid",
|
|
|
|
|
[](nanobind::object & /*class*/) {
|
2023-05-22 11:12:53 -05:00
|
|
|
if (DerivedTy::getTypeIdFunction)
|
2025-09-20 14:47:32 -04:00
|
|
|
return PyTypeID(DerivedTy::getTypeIdFunction());
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
throw nanobind::attribute_error(
|
|
|
|
|
(DerivedTy::pyClassName + llvm::Twine(" has no typeid."))
|
|
|
|
|
.str()
|
|
|
|
|
.c_str());
|
2025-09-20 14:47:32 -04:00
|
|
|
},
|
|
|
|
|
nanobind::sig("def static_typeid(/) -> TypeID"));
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
cls.def_prop_ro("typeid", [](PyType &self) {
|
2025-09-20 14:47:32 -04:00
|
|
|
return nanobind::cast<PyTypeID>(nanobind::cast(self).attr("typeid"));
|
2023-05-22 11:12:53 -05:00
|
|
|
});
|
|
|
|
|
cls.def("__repr__", [](DerivedTy &self) {
|
|
|
|
|
PyPrintAccumulator printAccum;
|
|
|
|
|
printAccum.parts.append(DerivedTy::pyClassName);
|
|
|
|
|
printAccum.parts.append("(");
|
|
|
|
|
mlirTypePrint(self, printAccum.getCallback(), printAccum.getUserData());
|
|
|
|
|
printAccum.parts.append(")");
|
|
|
|
|
return printAccum.join();
|
|
|
|
|
});
|
|
|
|
|
|
2023-05-26 10:23:17 -05:00
|
|
|
if (DerivedTy::getTypeIdFunction) {
|
|
|
|
|
PyGlobals::get().registerTypeCaster(
|
|
|
|
|
DerivedTy::getTypeIdFunction(),
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::cast<nanobind::callable>(nanobind::cpp_function(
|
|
|
|
|
[](PyType pyType) -> DerivedTy { return pyType; })));
|
2023-05-26 10:23:17 -05:00
|
|
|
}
|
|
|
|
|
|
2021-10-14 17:19:06 +02:00
|
|
|
DerivedTy::bindDerived(cls);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Implemented by derived classes to add methods to the Python subclass.
|
|
|
|
|
static void bindDerived(ClassTy &m) {}
|
|
|
|
|
};
|
2020-10-28 23:16:36 -07:00
|
|
|
|
2020-08-19 15:33:02 -07:00
|
|
|
/// Wrapper around the generic MlirAttribute.
|
|
|
|
|
/// The lifetime of a type is bound by the PyContext that created it.
|
2020-09-18 00:21:09 -07:00
|
|
|
class PyAttribute : public BaseContextObject {
|
2020-08-19 15:33:02 -07:00
|
|
|
public:
|
2020-09-18 00:21:09 -07:00
|
|
|
PyAttribute(PyMlirContextRef contextRef, MlirAttribute attr)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), attr(attr) {}
|
2023-03-28 11:05:00 -04:00
|
|
|
bool operator==(const PyAttribute &other) const;
|
2020-11-29 13:30:23 -08:00
|
|
|
operator MlirAttribute() const { return attr; }
|
|
|
|
|
MlirAttribute get() const { return attr; }
|
2020-08-19 15:33:02 -07:00
|
|
|
|
2021-01-26 10:40:21 +08:00
|
|
|
/// Gets a capsule wrapping the void* within the MlirAttribute.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2020-11-29 13:30:23 -08:00
|
|
|
|
2021-01-26 10:40:21 +08:00
|
|
|
/// Creates a PyAttribute from the MlirAttribute wrapped by a capsule.
|
|
|
|
|
/// Note that PyAttribute instances are uniqued, so the returned object
|
|
|
|
|
/// may be a pre-existing object. Ownership of the underlying MlirAttribute
|
2020-11-29 13:30:23 -08:00
|
|
|
/// is taken by calling this function.
|
2025-09-23 13:54:22 -04:00
|
|
|
static PyAttribute createFromCapsule(const nanobind::object &capsule);
|
2020-11-29 13:30:23 -08:00
|
|
|
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object maybeDownCast();
|
2025-09-20 14:47:32 -04:00
|
|
|
|
2020-11-29 13:30:23 -08:00
|
|
|
private:
|
2020-08-19 15:33:02 -07:00
|
|
|
MlirAttribute attr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/// Represents a Python MlirNamedAttr, carrying an optional owned name.
|
|
|
|
|
/// TODO: Refactor this and the C-API to be based on an Identifier owned
|
|
|
|
|
/// by the context so as to avoid ownership issues here.
|
|
|
|
|
class PyNamedAttribute {
|
|
|
|
|
public:
|
|
|
|
|
/// Constructs a PyNamedAttr that retains an owned name. This should be
|
|
|
|
|
/// used in any code that originates an MlirNamedAttribute from a python
|
|
|
|
|
/// string.
|
|
|
|
|
/// The lifetime of the PyNamedAttr must extend to the lifetime of the
|
|
|
|
|
/// passed attribute.
|
|
|
|
|
PyNamedAttribute(MlirAttribute attr, std::string ownedName);
|
|
|
|
|
|
|
|
|
|
MlirNamedAttribute namedAttr;
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
// Since the MlirNamedAttr contains an internal pointer to the actual
|
|
|
|
|
// memory of the owned string, it must be heap allocated to remain valid.
|
|
|
|
|
// Otherwise, strings that fit within the small object optimization threshold
|
|
|
|
|
// will have their memory address change as the containing object is moved,
|
|
|
|
|
// resulting in an invalid aliased pointer.
|
|
|
|
|
std::unique_ptr<std::string> ownedName;
|
|
|
|
|
};
|
|
|
|
|
|
2021-04-22 15:52:01 +02:00
|
|
|
/// CRTP base classes for Python attributes that subclass Attribute and should
|
|
|
|
|
/// be castable from it (i.e. via something like StringAttr(attr)).
|
|
|
|
|
/// By default, attribute class hierarchies are one level deep (i.e. a
|
|
|
|
|
/// concrete attribute class extends PyAttribute); however, intermediate
|
|
|
|
|
/// python-visible base classes can be modeled by specifying a BaseTy.
|
|
|
|
|
template <typename DerivedTy, typename BaseTy = PyAttribute>
|
|
|
|
|
class PyConcreteAttribute : public BaseTy {
|
|
|
|
|
public:
|
|
|
|
|
// Derived classes must define statics for:
|
|
|
|
|
// IsAFunctionTy isaFunction
|
|
|
|
|
// const char *pyClassName
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
using ClassTy = nanobind::class_<DerivedTy, BaseTy>;
|
2021-04-22 15:52:01 +02:00
|
|
|
using IsAFunctionTy = bool (*)(MlirAttribute);
|
2023-05-31 15:52:46 -05:00
|
|
|
using GetTypeIDFunctionTy = MlirTypeID (*)();
|
|
|
|
|
static constexpr GetTypeIDFunctionTy getTypeIdFunction = nullptr;
|
2021-04-22 15:52:01 +02:00
|
|
|
|
|
|
|
|
PyConcreteAttribute() = default;
|
|
|
|
|
PyConcreteAttribute(PyMlirContextRef contextRef, MlirAttribute attr)
|
|
|
|
|
: BaseTy(std::move(contextRef), attr) {}
|
|
|
|
|
PyConcreteAttribute(PyAttribute &orig)
|
|
|
|
|
: PyConcreteAttribute(orig.getContext(), castFrom(orig)) {}
|
|
|
|
|
|
|
|
|
|
static MlirAttribute castFrom(PyAttribute &orig) {
|
|
|
|
|
if (!DerivedTy::isaFunction(orig)) {
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
auto origRepr =
|
|
|
|
|
nanobind::cast<std::string>(nanobind::repr(nanobind::cast(orig)));
|
|
|
|
|
throw nanobind::value_error((llvm::Twine("Cannot cast attribute to ") +
|
|
|
|
|
DerivedTy::pyClassName + " (from " +
|
|
|
|
|
origRepr + ")")
|
|
|
|
|
.str()
|
|
|
|
|
.c_str());
|
2021-04-22 15:52:01 +02:00
|
|
|
}
|
|
|
|
|
return orig;
|
|
|
|
|
}
|
|
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static void bind(nanobind::module_ &m, PyType_Slot *slots = nullptr) {
|
|
|
|
|
ClassTy cls;
|
|
|
|
|
if (slots) {
|
|
|
|
|
cls = ClassTy(m, DerivedTy::pyClassName, nanobind::type_slots(slots));
|
|
|
|
|
} else {
|
|
|
|
|
cls = ClassTy(m, DerivedTy::pyClassName);
|
|
|
|
|
}
|
|
|
|
|
cls.def(nanobind::init<PyAttribute &>(), nanobind::keep_alive<0, 1>(),
|
|
|
|
|
nanobind::arg("cast_from_attr"));
|
2021-11-28 14:08:06 -08:00
|
|
|
cls.def_static(
|
|
|
|
|
"isinstance",
|
|
|
|
|
[](PyAttribute &otherAttr) -> bool {
|
|
|
|
|
return DerivedTy::isaFunction(otherAttr);
|
|
|
|
|
},
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::arg("other"));
|
2025-09-23 13:54:22 -04:00
|
|
|
cls.def_prop_ro(
|
|
|
|
|
"type",
|
|
|
|
|
[](PyAttribute &attr) -> nanobind::typed<nanobind::object, PyType> {
|
|
|
|
|
return PyType(attr.getContext(), mlirAttributeGetType(attr))
|
|
|
|
|
.maybeDownCast();
|
|
|
|
|
});
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
cls.def_prop_ro_static(
|
2025-09-20 14:47:32 -04:00
|
|
|
"static_typeid",
|
|
|
|
|
[](nanobind::object & /*class*/) -> PyTypeID {
|
2023-05-31 15:52:46 -05:00
|
|
|
if (DerivedTy::getTypeIdFunction)
|
2025-09-20 14:47:32 -04:00
|
|
|
return PyTypeID(DerivedTy::getTypeIdFunction());
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
throw nanobind::attribute_error(
|
|
|
|
|
(DerivedTy::pyClassName + llvm::Twine(" has no typeid."))
|
|
|
|
|
.str()
|
|
|
|
|
.c_str());
|
2025-09-20 14:47:32 -04:00
|
|
|
},
|
|
|
|
|
nanobind::sig("def static_typeid(/) -> TypeID"));
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
cls.def_prop_ro("typeid", [](PyAttribute &self) {
|
2025-09-20 14:47:32 -04:00
|
|
|
return nanobind::cast<PyTypeID>(nanobind::cast(self).attr("typeid"));
|
2023-05-31 15:52:46 -05:00
|
|
|
});
|
|
|
|
|
cls.def("__repr__", [](DerivedTy &self) {
|
|
|
|
|
PyPrintAccumulator printAccum;
|
|
|
|
|
printAccum.parts.append(DerivedTy::pyClassName);
|
|
|
|
|
printAccum.parts.append("(");
|
|
|
|
|
mlirAttributePrint(self, printAccum.getCallback(),
|
|
|
|
|
printAccum.getUserData());
|
|
|
|
|
printAccum.parts.append(")");
|
|
|
|
|
return printAccum.join();
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
if (DerivedTy::getTypeIdFunction) {
|
|
|
|
|
PyGlobals::get().registerTypeCaster(
|
|
|
|
|
DerivedTy::getTypeIdFunction(),
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::cast<nanobind::callable>(
|
|
|
|
|
nanobind::cpp_function([](PyAttribute pyAttribute) -> DerivedTy {
|
|
|
|
|
return pyAttribute;
|
|
|
|
|
})));
|
2023-05-31 15:52:46 -05:00
|
|
|
}
|
|
|
|
|
|
2021-04-28 16:16:45 -07:00
|
|
|
DerivedTy::bindDerived(cls);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Implemented by derived classes to add methods to the Python subclass.
|
|
|
|
|
static void bindDerived(ClassTy &m) {}
|
|
|
|
|
};
|
|
|
|
|
|
2025-09-20 14:47:32 -04:00
|
|
|
class PyStringAttribute : public PyConcreteAttribute<PyStringAttribute> {
|
|
|
|
|
public:
|
|
|
|
|
static constexpr IsAFunctionTy isaFunction = mlirAttributeIsAString;
|
|
|
|
|
static constexpr const char *pyClassName = "StringAttr";
|
|
|
|
|
using PyConcreteAttribute::PyConcreteAttribute;
|
|
|
|
|
static constexpr GetTypeIDFunctionTy getTypeIdFunction =
|
|
|
|
|
mlirStringAttrGetTypeID;
|
|
|
|
|
|
|
|
|
|
static void bindDerived(ClassTy &c);
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-20 11:21:05 +02:00
|
|
|
/// Wrapper around the generic MlirValue.
|
|
|
|
|
/// Values are managed completely by the operation that resulted in their
|
|
|
|
|
/// definition. For op result value, this is the operation that defines the
|
|
|
|
|
/// value. For block argument values, this is the operation that contains the
|
|
|
|
|
/// block to which the value is an argument (blocks cannot be detached in Python
|
|
|
|
|
/// bindings so such operation always exists).
|
|
|
|
|
class PyValue {
|
|
|
|
|
public:
|
[mlir][python] value casting (#69644)
This PR adds "value casting", i.e., a mechanism to wrap `ir.Value` in a
proxy class that overloads dunders such as `__add__`, `__sub__`, and
`__mul__` for fun and great profit.
This is thematically similar to
https://github.com/llvm/llvm-project/commit/bfb1ba752655bf09b35c486f6cc9817dbedfb1bb
and
https://github.com/llvm/llvm-project/commit/9566ee280607d91fa2e5eca730a6765ac84dfd0f.
The example in the test demonstrates the value of the feature (no pun
intended):
```python
@register_value_caster(F16Type.static_typeid)
@register_value_caster(F32Type.static_typeid)
@register_value_caster(F64Type.static_typeid)
@register_value_caster(IntegerType.static_typeid)
class ArithValue(Value):
__add__ = partialmethod(_binary_op, op="add")
__sub__ = partialmethod(_binary_op, op="sub")
__mul__ = partialmethod(_binary_op, op="mul")
a = arith.constant(value=FloatAttr.get(f16_t, 42.42))
b = a + a
# CHECK: ArithValue(%0 = arith.addf %cst, %cst : f16)
print(b)
a = arith.constant(value=FloatAttr.get(f32_t, 42.42))
b = a - a
# CHECK: ArithValue(%1 = arith.subf %cst_0, %cst_0 : f32)
print(b)
a = arith.constant(value=FloatAttr.get(f64_t, 42.42))
b = a * a
# CHECK: ArithValue(%2 = arith.mulf %cst_1, %cst_1 : f64)
print(b)
```
**EDIT**: this now goes through the bindings and thus supports automatic
casting of `OpResult` (including as an element of `OpResultList`),
`BlockArgument` (including as an element of `BlockArgumentList`), as
well as `Value`.
2023-11-07 10:49:41 -06:00
|
|
|
// The virtual here is "load bearing" in that it enables RTTI
|
|
|
|
|
// for PyConcreteValue CRTP classes that support maybeDownCast.
|
|
|
|
|
// See PyValue::maybeDownCast.
|
|
|
|
|
virtual ~PyValue() = default;
|
2020-10-20 11:21:05 +02:00
|
|
|
PyValue(PyOperationRef parentOperation, MlirValue value)
|
2022-01-14 01:35:55 +00:00
|
|
|
: parentOperation(std::move(parentOperation)), value(value) {}
|
2021-10-11 18:24:48 +02:00
|
|
|
operator MlirValue() const { return value; }
|
2020-10-20 11:21:05 +02:00
|
|
|
|
|
|
|
|
MlirValue get() { return value; }
|
|
|
|
|
PyOperationRef &getParentOperation() { return parentOperation; }
|
|
|
|
|
|
|
|
|
|
void checkValid() { return parentOperation->checkValid(); }
|
|
|
|
|
|
2021-04-22 00:07:30 -06:00
|
|
|
/// Gets a capsule wrapping the void* within the MlirValue.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2021-04-22 00:07:30 -06:00
|
|
|
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object maybeDownCast();
|
[mlir][python] value casting (#69644)
This PR adds "value casting", i.e., a mechanism to wrap `ir.Value` in a
proxy class that overloads dunders such as `__add__`, `__sub__`, and
`__mul__` for fun and great profit.
This is thematically similar to
https://github.com/llvm/llvm-project/commit/bfb1ba752655bf09b35c486f6cc9817dbedfb1bb
and
https://github.com/llvm/llvm-project/commit/9566ee280607d91fa2e5eca730a6765ac84dfd0f.
The example in the test demonstrates the value of the feature (no pun
intended):
```python
@register_value_caster(F16Type.static_typeid)
@register_value_caster(F32Type.static_typeid)
@register_value_caster(F64Type.static_typeid)
@register_value_caster(IntegerType.static_typeid)
class ArithValue(Value):
__add__ = partialmethod(_binary_op, op="add")
__sub__ = partialmethod(_binary_op, op="sub")
__mul__ = partialmethod(_binary_op, op="mul")
a = arith.constant(value=FloatAttr.get(f16_t, 42.42))
b = a + a
# CHECK: ArithValue(%0 = arith.addf %cst, %cst : f16)
print(b)
a = arith.constant(value=FloatAttr.get(f32_t, 42.42))
b = a - a
# CHECK: ArithValue(%1 = arith.subf %cst_0, %cst_0 : f32)
print(b)
a = arith.constant(value=FloatAttr.get(f64_t, 42.42))
b = a * a
# CHECK: ArithValue(%2 = arith.mulf %cst_1, %cst_1 : f64)
print(b)
```
**EDIT**: this now goes through the bindings and thus supports automatic
casting of `OpResult` (including as an element of `OpResultList`),
`BlockArgument` (including as an element of `BlockArgumentList`), as
well as `Value`.
2023-11-07 10:49:41 -06:00
|
|
|
|
2021-04-22 00:07:30 -06:00
|
|
|
/// Creates a PyValue from the MlirValue wrapped by a capsule. Ownership of
|
|
|
|
|
/// the underlying MlirValue is still tied to the owning operation.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
static PyValue createFromCapsule(nanobind::object capsule);
|
2021-04-22 00:07:30 -06:00
|
|
|
|
2020-10-20 11:21:05 +02:00
|
|
|
private:
|
|
|
|
|
PyOperationRef parentOperation;
|
|
|
|
|
MlirValue value;
|
|
|
|
|
};
|
|
|
|
|
|
2021-01-07 11:09:09 +01:00
|
|
|
/// Wrapper around MlirAffineExpr. Affine expressions are owned by the context.
|
|
|
|
|
class PyAffineExpr : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyAffineExpr(PyMlirContextRef contextRef, MlirAffineExpr affineExpr)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), affineExpr(affineExpr) {}
|
2023-03-28 11:05:00 -04:00
|
|
|
bool operator==(const PyAffineExpr &other) const;
|
2021-01-07 11:09:09 +01:00
|
|
|
operator MlirAffineExpr() const { return affineExpr; }
|
|
|
|
|
MlirAffineExpr get() const { return affineExpr; }
|
|
|
|
|
|
|
|
|
|
/// Gets a capsule wrapping the void* within the MlirAffineExpr.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2021-01-07 11:09:09 +01:00
|
|
|
|
|
|
|
|
/// Creates a PyAffineExpr from the MlirAffineExpr wrapped by a capsule.
|
|
|
|
|
/// Note that PyAffineExpr instances are uniqued, so the returned object
|
|
|
|
|
/// may be a pre-existing object. Ownership of the underlying MlirAffineExpr
|
|
|
|
|
/// is taken by calling this function.
|
2025-08-21 04:55:22 -07:00
|
|
|
static PyAffineExpr createFromCapsule(const nanobind::object &capsule);
|
2021-01-07 11:09:09 +01:00
|
|
|
|
|
|
|
|
PyAffineExpr add(const PyAffineExpr &other) const;
|
|
|
|
|
PyAffineExpr mul(const PyAffineExpr &other) const;
|
|
|
|
|
PyAffineExpr floorDiv(const PyAffineExpr &other) const;
|
|
|
|
|
PyAffineExpr ceilDiv(const PyAffineExpr &other) const;
|
|
|
|
|
PyAffineExpr mod(const PyAffineExpr &other) const;
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirAffineExpr affineExpr;
|
|
|
|
|
};
|
|
|
|
|
|
2020-12-14 18:43:05 +08:00
|
|
|
class PyAffineMap : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyAffineMap(PyMlirContextRef contextRef, MlirAffineMap affineMap)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), affineMap(affineMap) {}
|
2023-03-28 11:05:00 -04:00
|
|
|
bool operator==(const PyAffineMap &other) const;
|
2020-12-14 18:43:05 +08:00
|
|
|
operator MlirAffineMap() const { return affineMap; }
|
|
|
|
|
MlirAffineMap get() const { return affineMap; }
|
|
|
|
|
|
|
|
|
|
/// Gets a capsule wrapping the void* within the MlirAffineMap.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2020-12-14 18:43:05 +08:00
|
|
|
|
|
|
|
|
/// Creates a PyAffineMap from the MlirAffineMap wrapped by a capsule.
|
|
|
|
|
/// Note that PyAffineMap instances are uniqued, so the returned object
|
|
|
|
|
/// may be a pre-existing object. Ownership of the underlying MlirAffineMap
|
|
|
|
|
/// is taken by calling this function.
|
2025-08-21 04:55:22 -07:00
|
|
|
static PyAffineMap createFromCapsule(const nanobind::object &capsule);
|
2020-12-14 18:43:05 +08:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirAffineMap affineMap;
|
|
|
|
|
};
|
|
|
|
|
|
2021-01-25 18:17:19 +01:00
|
|
|
class PyIntegerSet : public BaseContextObject {
|
|
|
|
|
public:
|
|
|
|
|
PyIntegerSet(PyMlirContextRef contextRef, MlirIntegerSet integerSet)
|
|
|
|
|
: BaseContextObject(std::move(contextRef)), integerSet(integerSet) {}
|
2023-03-28 11:05:00 -04:00
|
|
|
bool operator==(const PyIntegerSet &other) const;
|
2021-01-25 18:17:19 +01:00
|
|
|
operator MlirIntegerSet() const { return integerSet; }
|
|
|
|
|
MlirIntegerSet get() const { return integerSet; }
|
|
|
|
|
|
|
|
|
|
/// Gets a capsule wrapping the void* within the MlirIntegerSet.
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object getCapsule();
|
2021-01-25 18:17:19 +01:00
|
|
|
|
|
|
|
|
/// Creates a PyIntegerSet from the MlirAffineMap wrapped by a capsule.
|
|
|
|
|
/// Note that PyIntegerSet instances may be uniqued, so the returned object
|
|
|
|
|
/// may be a pre-existing object. Integer sets are owned by the context.
|
2025-08-21 04:55:22 -07:00
|
|
|
static PyIntegerSet createFromCapsule(const nanobind::object &capsule);
|
2021-01-25 18:17:19 +01:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
MlirIntegerSet integerSet;
|
|
|
|
|
};
|
|
|
|
|
|
2021-11-02 12:39:36 +01:00
|
|
|
/// Bindings for MLIR symbol tables.
|
|
|
|
|
class PySymbolTable {
|
|
|
|
|
public:
|
|
|
|
|
/// Constructs a symbol table for the given operation.
|
|
|
|
|
explicit PySymbolTable(PyOperationBase &operation);
|
|
|
|
|
|
|
|
|
|
/// Destroys the symbol table.
|
|
|
|
|
~PySymbolTable() { mlirSymbolTableDestroy(symbolTable); }
|
|
|
|
|
|
|
|
|
|
/// Returns the symbol (opview) with the given name, throws if there is no
|
|
|
|
|
/// such symbol in the table.
|
2025-09-22 15:55:43 -04:00
|
|
|
nanobind::object dunderGetItem(const std::string &name);
|
2021-11-02 12:39:36 +01:00
|
|
|
|
|
|
|
|
/// Removes the given operation from the symbol table and erases it.
|
|
|
|
|
void erase(PyOperationBase &symbol);
|
|
|
|
|
|
|
|
|
|
/// Removes the operation with the given name from the symbol table and erases
|
|
|
|
|
/// it, throws if there is no such symbol in the table.
|
|
|
|
|
void dunderDel(const std::string &name);
|
|
|
|
|
|
|
|
|
|
/// Inserts the given operation into the symbol table. The operation must have
|
|
|
|
|
/// the symbol trait.
|
2025-09-20 14:47:32 -04:00
|
|
|
PyStringAttribute insert(PyOperationBase &symbol);
|
2021-11-02 12:39:36 +01:00
|
|
|
|
2021-11-28 20:30:18 -08:00
|
|
|
/// Gets and sets the name of a symbol op.
|
2025-09-20 14:47:32 -04:00
|
|
|
static PyStringAttribute getSymbolName(PyOperationBase &symbol);
|
2021-11-28 20:30:18 -08:00
|
|
|
static void setSymbolName(PyOperationBase &symbol, const std::string &name);
|
|
|
|
|
|
|
|
|
|
/// Gets and sets the visibility of a symbol op.
|
2025-09-20 14:47:32 -04:00
|
|
|
static PyStringAttribute getVisibility(PyOperationBase &symbol);
|
2021-11-28 20:30:18 -08:00
|
|
|
static void setVisibility(PyOperationBase &symbol,
|
|
|
|
|
const std::string &visibility);
|
|
|
|
|
|
|
|
|
|
/// Replaces all symbol uses within an operation. See the API
|
|
|
|
|
/// mlirSymbolTableReplaceAllSymbolUses for all caveats.
|
|
|
|
|
static void replaceAllSymbolUses(const std::string &oldSymbol,
|
|
|
|
|
const std::string &newSymbol,
|
|
|
|
|
PyOperationBase &from);
|
|
|
|
|
|
|
|
|
|
/// Walks all symbol tables under and including 'from'.
|
|
|
|
|
static void walkSymbolTables(PyOperationBase &from, bool allSymUsesVisible,
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
nanobind::object callback);
|
2021-11-28 20:30:18 -08:00
|
|
|
|
2021-11-02 12:39:36 +01:00
|
|
|
/// Casts the bindings class into the C API structure.
|
|
|
|
|
operator MlirSymbolTable() { return symbolTable; }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
PyOperationRef operation;
|
|
|
|
|
MlirSymbolTable symbolTable;
|
|
|
|
|
};
|
|
|
|
|
|
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```
The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
... Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
... print(e.message)
... print(e.error_diagnostics)
... print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- `Operation.verify` now raises an exception on verification failure,
instead of returning `false`
- The exception raised by the following methods has been changed to
`MLIRError`:
- `PassManager.run`
- `{Module,Operation,Type,Attribute}.parse`
- `{RankedTensorType,UnrankedTensorType}.get`
- `{MemRefType,UnrankedMemRefType}.get`
- `VectorType.get`
- `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
2023-02-07 16:07:50 -05:00
|
|
|
/// Custom exception that allows access to error diagnostic information. This is
|
|
|
|
|
/// converted to the `ir.MLIRError` python exception when thrown.
|
|
|
|
|
struct MLIRError {
|
|
|
|
|
MLIRError(llvm::Twine message,
|
|
|
|
|
std::vector<PyDiagnostic::DiagnosticInfo> &&errorDiagnostics = {})
|
|
|
|
|
: message(message.str()), errorDiagnostics(std::move(errorDiagnostics)) {}
|
|
|
|
|
std::string message;
|
|
|
|
|
std::vector<PyDiagnostic::DiagnosticInfo> errorDiagnostics;
|
|
|
|
|
};
|
|
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
void populateIRAffine(nanobind::module_ &m);
|
|
|
|
|
void populateIRAttributes(nanobind::module_ &m);
|
|
|
|
|
void populateIRCore(nanobind::module_ &m);
|
|
|
|
|
void populateIRInterfaces(nanobind::module_ &m);
|
|
|
|
|
void populateIRTypes(nanobind::module_ &m);
|
2020-08-16 20:53:45 -07:00
|
|
|
|
|
|
|
|
} // namespace python
|
|
|
|
|
} // namespace mlir
|
2020-08-16 18:49:28 -07:00
|
|
|
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
namespace nanobind {
|
2020-10-31 23:40:25 -07:00
|
|
|
namespace detail {
|
|
|
|
|
|
|
|
|
|
template <>
|
|
|
|
|
struct type_caster<mlir::python::DefaultingPyMlirContext>
|
|
|
|
|
: MlirDefaultingCaster<mlir::python::DefaultingPyMlirContext> {};
|
|
|
|
|
template <>
|
|
|
|
|
struct type_caster<mlir::python::DefaultingPyLocation>
|
|
|
|
|
: MlirDefaultingCaster<mlir::python::DefaultingPyLocation> {};
|
|
|
|
|
|
|
|
|
|
} // namespace detail
|
[mlir python] Port Python core code to nanobind. (#120473)
Relands #118583, with a fix for Python 3.8 compatibility. It was not
possible to set the buffer protocol accessers via slots in Python 3.8.
Why? https://nanobind.readthedocs.io/en/latest/why.html says it better
than I can, but my primary motivation for this change is to improve MLIR
IR construction time from JAX.
For a complicated Google-internal LLM model in JAX, this change improves
the MLIR
lowering time by around 5s (out of around 30s), which is a significant
speedup for simply switching binding frameworks.
To a large extent, this is a mechanical change, for instance changing
`pybind11::` to `nanobind::`.
Notes:
* this PR needs Nanobind 2.4.0, because it needs a bug fix
(https://github.com/wjakob/nanobind/pull/806) that landed in that
release.
* this PR does not port the in-tree dialect extension modules. They can
be ported in a future PR.
* I removed the py::sibling() annotations from def_static and def_class
in `PybindAdapters.h`. These ask pybind11 to try to form an overload
with an existing method, but it's not possible to form mixed
pybind11/nanobind overloads this ways and the parent class is now
defined in nanobind. Better solutions may be possible here.
* nanobind does not contain an exact equivalent of pybind11's buffer
protocol support. It was not hard to add a nanobind implementation of a
similar API.
* nanobind is pickier about casting to std::vector<bool>, expecting that
the input is a sequence of bool types, not truthy values. In a couple of
places I added code to support truthy values during casting.
* nanobind distinguishes bytes (`nb::bytes`) from strings (e.g.,
`std::string`). This required nb::bytes overloads in a few places.
2024-12-18 21:55:42 -05:00
|
|
|
} // namespace nanobind
|
2020-10-31 23:40:25 -07:00
|
|
|
|
2020-08-16 18:49:28 -07:00
|
|
|
#endif // MLIR_BINDINGS_PYTHON_IRMODULES_H
|