This involved a little bit of yak shaving because one of the new tests
depends on MPC, and we didn't have targets for it yet, so I ended up
needing to add a similar setup to what we have for MPFR.
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.
Previously these targets were disabled, but with a relatively new
rules_python we can build these pointing at a hermetic python, which
allows us to build these safely. Users can still access the files
directly if they need to customize how these are built.
This target doesn't build on macOS (even with the upstream make based
build system) so this encodes that in the build without requiring
non-linux users to disable it manually with the starlark flag. The flag
is still respected for linux users.
Switches the library to use the zlib-ng implementation since the
original implementation is warning-incompatible with recent versions of clang.
Removes the wrapper logic for zlib in the bazel build and introduces new
logic to handle `LLVM_ENABLE_ZLIB`.
Removes the `BAZEL_LLVM_ZLIB_STRATEGY` environment variable and instead
introduces a boolean `--@llvm_zlib//:llvm_enable_zlib` flag which defaults
to true.
To migrate:
* The previous "external" strategy is the default. May be explicitly
enabled with `--@llvm_zlib//:llvm_enable_zlib=true`. For custom zlib
variants you can use the BUILD file at `third_party_build/zlib.BUILD`
as reference and adjust the `@llvm_zlib` archive in the `WORKSPACE`
directly.
* The previous "disable" strategy may be enabled with
`--@llvm_zlib//:llvm_enable_zlib=false`.
* The previous "system" strategy has been removed since it breaks
hermeticity. If you need the "system" setup, use the "external"
strategy and override the zlib dependency.
Addresses breakages of downstream projects using upstream clang and the
previously "external" zlib strategy (D141553).
Reviewed By: MaskRay, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D143320
Originally added in D128465. Used by `llvm:Support` and `lld:ELF`.
Enabled by default. Disable with `--@llvm_zstd//:llvm_enable_zstd=false`.
Reviewed By: MaskRay, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D143344
We used to have `pfm` built into exegesis, although since it's an external dependency we marked it as a manual target. Because of this we didn't have buildbot coverage and so we removed it in D134510 after we had a few breakages that weren't caught. This adds it back, but with three possible states similar to the story with `mpfr`, i.e. it can either be disabled, built from external sources (git/make), or use whatever `-lpfm` is installed on the system.
This change is modeled after D119547. Like that patch, the default is off (matching the status quo), but unlike that patch we don't enable it for CI because IIRC we don't have the package installed there, and building from source might be expensive. We could enable it later either after installing it on buildbot machines or by measuring build cost and deeming it OK.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D138470
This patch adds bazel tests for llvm-libc.
Some math tests rely on the `mpfr` library. This is controlled via the `--@llvm-project//libc:libc_math_mpfr` flag. It can take three values:
- `external` (default) will build `mpfr` and `gmp` from source.
- `system` will use the system installed `mpfr` library.
- `disable` will skip tests relying on `mpfr`.
Reviewed By: sivachandra, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D119547
@GMNGeoffrey let me know it there's a better way to import MPFR and GMP for the purpose of testing libc math functions.
Differential Revision: https://reviews.llvm.org/D119547
