| commit | e4c27f5842e0ad58b1a6a1dd27443cb49d87b32c | [log] [tgz] |
|---|---|---|
| author | bjacob <benoitjacob@google.com> | Fri Jun 09 14:44:05 2023 -0400 |
| committer | GitHub <noreply@github.com> | Fri Jun 09 14:44:05 2023 -0400 |
| tree | fd0162382a3869842019d211414ff201d1caa15c | |
| parent | b3a1ac9e8592f911195fa829ca1b13a280da4c73 [diff] |
Support non-default sets of enabled LLVM CPU targets. (#13983) A number of places in our bitcode build, tests and samples were still relying on specific LLVM CPU targets, namely `X86` and `AArch64`, which are part of what's enabled from our standard list for our bundled build: https://github.com/openxla/iree/blob/815e84310740ba2bd181438f4fc8224406951ea9/build_tools/cmake/iree_llvm.cmake#L108 Since this is a `CACHE`'d CMake variable, it was always possible for a user to disable some of these targets. Probably many people tried that, in the hopes of getting faster builds. But lately, as we added bitcode libraries and standalone plugins that unconditionally built a fixed set of target architecture, that was no longer working. The recent development motivating this now is bring-your-own-LLVM: the `byo_llvm.sh` script is defaulting to enabling only the `X86` target: https://github.com/openxla/iree/blob/815e84310740ba2bd181438f4fc8224406951ea9/build_tools/scripts/byo_llvm.sh#L72 Even if that's only an invitation to the user to adapt it to their needs, that's a departure from the standard sets of targets that we were relying on. In particular, x86 users who would run this script unmodified would run into these build issues if they try to build all of IREE with its compiler, tests and samples. So this PR makes us mostly principled in this respect. The remaining un-principled aspects that I know of are: * When building the compiler with the `llvm-cpu` backend, we have an implicit assumption that at least the LLVM target for the target architecture is built. * We are relying on the `WebAssembly` target always being built, as it is what we use in non-architecture-specific `iree_bitcode_library`'s as a proxy for "a reasonable 32-bit / 64-bit architecture" where we are going to be stripping away target information from the IR. * This reliance should not be a problem in the near term as we are enabling `WebAssembly` by default, in a way that is orthogonal to `byo-llvm.sh`. In order to run into trouble, a user would have to explicitly turn off `IREE_TARGET_BACKEND_LLVM_CPU_WASM`. --------- Co-authored-by: Scott Todd <scotttodd@google.com>
IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler and runtime that lowers Machine Learning (ML) models to a unified IR that scales up to meet the needs of the datacenter and down to satisfy the constraints and special considerations of mobile and edge deployments.
See our website for project details, user guides, and instructions on building from source.
IREE is still in its early phase. We have settled down on the overarching infrastructure and are actively improving various software components as well as project logistics. It is still quite far from ready for everyday use and is made available without any support at the moment. With that said, we welcome any kind of feedback on any communication channels!
See our website for more information.
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.