From 8082562372261b49808d3288ef9ac21bd94f6ac7 Mon Sep 17 00:00:00 2001 From: Folkert de Vries Date: Tue, 15 Jul 2025 20:56:30 +0200 Subject: [PATCH 1/3] add proposal 'production-ready cranelift' --- src/2025h2/production-ready-cranelift.md | 69 ++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 src/2025h2/production-ready-cranelift.md diff --git a/src/2025h2/production-ready-cranelift.md b/src/2025h2/production-ready-cranelift.md new file mode 100644 index 00000000..ac87ec1b --- /dev/null +++ b/src/2025h2/production-ready-cranelift.md @@ -0,0 +1,69 @@ +# Production-ready cranelift backend + +| Metadata | | +| :--------------- | -------------------- | +| Point of contact | @folkertdev | +| Teams | T-compiler, T-perf | +| Task owners | @bjorn3, @folkertdev | +| Status | Proposed | +| Tracking issue | | +| Zulip channel | | + +## Summary + +This project aims to get the rust cranelift codegen backend to a production-ready state. Specifically, with this work completed, we'd be confident to recommend it as the default for local development, e.g. with `cargo test` or `cargo run`. + +## Motivation + +Compile-time performance consistently comes up as a limiting factor in the use and enjoyment of rust. Through extensive tracking and the hard work of T-perf and others, performance has gradually improved over the years. However, in practical terms, a 1% improvement here and there is not sufficient to truly improve users' workflows. + +The cranelift codegen backend (`rustc_codegen_cranelift`) is one of the most concrete ways we have to deliver a serious improvement to compile times in the typical development cycle. In our measurements on larger projects (e.g. Zed, Tauri, hickory-dns), we currently see roughly a 20% reduction of code generation time, translating to around 5% speedup of total compilation time for clean builds. + +Currently, this backend still has some serious limitations that real-world code bases run into. This project goal aims to get the `rustc_codegen_cranelift` to a state where we can confidently recommend it for local development. + +## Status quo + +The cranelift backend is already very capable, and well-integrated into the rust project. It is able to re-use a lot of infrastructure and code, for instance via `rustc_codegen_ssa`. It can be enabled on a per-project basis in the `Cargo.toml`: + +```toml +# This line needs to come before anything else in Cargo.toml +cargo-features = ["codegen-backend"] + +[profile.dev] +codegen-backend = "cranelift" +``` + +It is however not quite stable and reliable enough for real use. Most large projects run into one or two missing features, meaning that `rustc_codegen_cranelift` cannot be used. Furthermore, small changes in the project and/or its dependencies could run into limitations of `rustc_codegen_cranelift`, so while experimentation with the backend is highly encouraged, we cannot currently recommend it for serious local development. + +## The next 6 months + +We plan to work on fixing the following cranelift limitations: + +- supporting unwinding (at least on Linux and macOS) +- fixing remaining ABI issues +- a better approach for supporting (SIMD) intrinsics + +As a side-effect we will also look at improving code sharing with rustc, for instance by moving more logic into `rustc_codegen_ssa`. These changes reduce the maintenance burden of the other backends (cranelift, but also `rustc_codegen_gcc`), and generally improves the code which is still quite over-fit to LLVM + +With these items completed, we believe that we can confidently recommend the use of the cranelift backend for local development and CI builds on linux and macOS. + +### The "shiny future" we are working towards + +We believe we can get to a production-ready `rustc_codegen_cranelift` implementation for Linux and macOS within the context of this project goal. The problems and solutions are mapped out, and there are many similarities between these targets. + +Ultimately, we'd like to provide the same level of quality for Windows, but this is much more challenging. Progress on this front is highly dependent on additional funding, and will take considerably more time. + +While this project aims to deliver a production-ready backend, it is by no means feature-complete at that point. One major missing feature is debug info (i.e. debugger support). + +More long-term we see the cranelift backend as an extremely promising approach for decreasing compile times, and substantially improving developer experience. However, significant technical work remains to be done to achieve that goal. We believe that the best next step towards this goal is to first get cranelift ready for widespread use, and then collectively work on further improving performance. + +## Ownership and team asks + +| Task | Owner(s) or team(s) | Notes | +| -------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | +| Acquire funding | Trifecta Tech Foundation @trifectatechfoundation | We will only be able to work on this project if it is funded | +| Standard reviews | ![Team][] [compiler] | Casual improvements to `rustc_codegen_ssa` and other parts of the backend | +| Dedicated reviewer | ![Team][] [compiler] | Larger changes to `rustc_codegen_ssa`. While not strictly required, we think having a dedicated reviewer will speed up our progress. | +| Deploy to production | ![Team][] [perf] | track and show `rustc_codegen_cranelift` performance | +| Do the work | bjorn3, folkertdev | | +## Frequently asked questions From ac51289fc8b41e1fdee653256804b93f6915d012 Mon Sep 17 00:00:00 2001 From: Folkert de Vries Date: Fri, 18 Jul 2025 13:57:46 +0200 Subject: [PATCH 2/3] Update src/2025h2/production-ready-cranelift.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jakub Beránek --- src/2025h2/production-ready-cranelift.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/2025h2/production-ready-cranelift.md b/src/2025h2/production-ready-cranelift.md index ac87ec1b..2b2a13dd 100644 --- a/src/2025h2/production-ready-cranelift.md +++ b/src/2025h2/production-ready-cranelift.md @@ -64,6 +64,6 @@ More long-term we see the cranelift backend as an extremely promising approach f | Acquire funding | Trifecta Tech Foundation @trifectatechfoundation | We will only be able to work on this project if it is funded | | Standard reviews | ![Team][] [compiler] | Casual improvements to `rustc_codegen_ssa` and other parts of the backend | | Dedicated reviewer | ![Team][] [compiler] | Larger changes to `rustc_codegen_ssa`. While not strictly required, we think having a dedicated reviewer will speed up our progress. | -| Deploy to production | ![Team][] [perf] | track and show `rustc_codegen_cranelift` performance | +| Deploy to production | ![Team][] [wg-compiler-performance] | track and show `rustc_codegen_cranelift` performance | | Do the work | bjorn3, folkertdev | | ## Frequently asked questions From bc746f30e2c73ca11c5ea81f17e32181a1422f7f Mon Sep 17 00:00:00 2001 From: Folkert de Vries Date: Fri, 18 Jul 2025 14:05:55 +0200 Subject: [PATCH 3/3] specify target architectures --- src/2025h2/production-ready-cranelift.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/2025h2/production-ready-cranelift.md b/src/2025h2/production-ready-cranelift.md index 2b2a13dd..8f6d29d4 100644 --- a/src/2025h2/production-ready-cranelift.md +++ b/src/2025h2/production-ready-cranelift.md @@ -49,7 +49,7 @@ With these items completed, we believe that we can confidently recommend the use ### The "shiny future" we are working towards -We believe we can get to a production-ready `rustc_codegen_cranelift` implementation for Linux and macOS within the context of this project goal. The problems and solutions are mapped out, and there are many similarities between these targets. +We believe we can get to a production-ready `rustc_codegen_cranelift` implementation for Linux and macOS, on `x86_64` and `aarch64`, within the context of this project goal. The problems and solutions are mapped out, and there are many similarities between these targets. Ultimately, we'd like to provide the same level of quality for Windows, but this is much more challenging. Progress on this front is highly dependent on additional funding, and will take considerably more time.