summaryrefslogtreecommitdiff
path: root/mlir/examples/standalone/test/python
AgeCommit message (Collapse)Author
2025-10-07Revert "[MLIR][Python] use `FetchContent_Declare` for nanobind and remove ↵Maksim Levental
pybind (#161230)" (#162309) This reverts commit 84a214856ad989f37af19f5e8aaa9ec2346dde6f. This gives us more time to work out the alternative and also people to migrate
2025-10-06[MLIR][Python] use `FetchContent_Declare` for nanobind and remove pybind ↵Maksim Levental
(#161230) Inspired by this comment https://github.com/llvm/llvm-project/pull/157930#issuecomment-3346634290 (and long-standing issues related to finding nanobind/pybind in the right place), this PR moves to using `FetchContent_Declare` to get the nanobind dependency. This is pretty standard (see e.g., [IREE](https://github.com/iree-org/iree/blob/cf60359b7443b0e92e15fb6ffc011525dc40e772/CMakeLists.txt#L842-L848)). This PR also removes pybind which has been deprecated for almost a year (https://github.com/llvm/llvm-project/pull/117922) and which isn't compatible (for whatever reason) with `FetchContent_Declare`. --------- Co-authored-by: Jacques Pienaar <jpienaar@google.com>
2025-09-24[MLIR][Standalone] use narrow registration instead of RegisterEverything ↵Maksim Levental
(#160469) This PR cleans up a long-standing TODO by avoiding `MLIRPythonExtension.RegisterEverything` in the Standalone example and registering the necessary dialects explicitly instead.
2024-12-09Revert "Revert "[mlir python] Add nanobind support (#119232)Maksim Levental
Reverts revert #118517 after (hopefully) fixing builders (https://github.com/llvm/llvm-zorg/pull/328, https://github.com/llvm/llvm-zorg/pull/327) This reverts commit 61bf308cf2fc32452f14861c102ace89f5f36fec.
2024-12-03Revert "[mlir python] Add nanobind support for standalone dialects." (#118517)Maksim Levental
Reverts llvm/llvm-project#117922 because deps aren't met on some of the post-commit build bots.
2024-12-03[mlir python] Add nanobind support for standalone dialects. (#117922)Peter Hawkins
This PR allows out-of-tree dialects to write Python dialect modules using nanobind instead of pybind11. It may make sense to migrate in-tree dialects and some of the ODS Python infrastructure to nanobind, but that is a topic for a future change. This PR makes the following changes: * adds nanobind to the CMake and Bazel build systems. We also add robin_map to the Bazel build, which is a dependency of nanobind. * adds a PYTHON_BINDING_LIBRARY option to various CMake functions, such as declare_mlir_python_extension, allowing users to select a Python binding library. * creates a fork of mlir/include/mlir/Bindings/Python/PybindAdaptors.h named NanobindAdaptors.h. This plays the same role, using nanobind instead of pybind11. * splits CollectDiagnosticsToStringScope out of PybindAdaptors.h and into a new header mlir/include/mlir/Bindings/Python/Diagnostics.h, since it is code that is no way related to pybind11 or for that matter, Python. * changed the standalone Python extension example to have both pybind11 and nanobind variants. * changed mlir/python/mlir/dialects/python_test.py to have both pybind11 and nanobind variants. Notes: * A slightly unfortunate thing that I needed to do in the CMake integration was to use FindPython in addition to FindPython3, since nanobind's CMake integration expects the Python_ names for variables. Perhaps there's a better way to do this.
2023-05-26[NFC][Py Reformat] Reformat python files in mlir subdirTobias Hieta
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black`. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782
2022-05-19[mlir] Remove unused properties from the standalone example's lit configurationStella Stamenova
Since these are unused, I've removed them from the configuration, so that it can be easier to read and follow. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D125132
2021-11-14Re-apply "[mlir] Allow out-of-tree python building from installed MLIR."Stella Laurenzo
Re-applies D111513: * Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled). * Rips out remnants of custom extension building in favor of pybind11_add_module which does the right thing. * Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API. * Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan). * Adds a ROOT_DIR argument to declare_mlir_python_extension since now all C++ sources for an extension must be under the same directory (to line up at install time). * Downstreams will need to adapt by: * Remove absolute paths from any SOURCES for declare_mlir_python_extension (I believe all downstreams are just using ${CMAKE_CURRENT_SOURCE_DIR} here, which can just be ommitted). May need to set ROOT_DIR if not relative to the current source directory. * To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for declare_mlir_python_extension. This reverts commit 1a6c26d1f52999edbfbf6a978ae3f0e6759ea755. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D113732
2021-11-12Revert "[mlir] Allow out-of-tree python building from installed MLIR."Mehdi Amini
This reverts commit c7be8b75399c727ec9e1ddc3f81510f284c65155. Build is broken (multiple buildbots)
2021-11-11[mlir] Allow out-of-tree python building from installed MLIR.Stella Laurenzo
* Depends on D111504, which provides the boilerplate for building aggregate shared libraries from installed MLIR. * Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled). * Rips out remnants of custom extension building in favor of `pybind11_add_module` which does the right thing. * Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API. * Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan). * Adds a ROOT_DIR argument to `declare_mlir_python_extension` since now all C++ sources for an extension must be under the same directory (to line up at install time). * Need to validate against a downstream or two and adjust, prior to submitting. Downstreams will need to adapt by: * Remove absolute paths from any SOURCES for `declare_mlir_python_extension` (I believe all downstreams are just using `${CMAKE_CURRENT_SOURCE_DIR}` here, which can just be ommitted). May need to set `ROOT_DIR` if not relative to the current source directory. * To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for `declare_mlir_python_extension`. Reviewed By: stephenneuendorffer, mikeurbach Differential Revision: https://reviews.llvm.org/D111513