Repository: rust
Issue: Tracking issue for speeding up rustc via its build configuration
Labels: T-compiler,C-tracking-issue,WG-compiler-performance

There are several ways to speed up rustc by changing its build configuration, without changing its code: use a single codegen unit (CGU), profile-guided optimization (PGO), link-time optimization (LTO), post-link optimization (via BOLT), and using a better allocator (e.g. jemalloc or mimalloc).

This is a tracking issue for doing these for the most popular Tier 1 platforms: Linux64 (`x86_64-unknown-linux-gnu`), Win64 (`x86_64-pc-windows-msvc`), and Mac (`x86_64-apple-darwin`, and more recently `aarch64-apple-darwin`).

Items marked with [2022] are on the [Compiler performance roadmap for 2022](https://hackmd.io/YJQSj_nLSZWl2sbI84R1qA).

### Single CGU

Benefits: rustc is faster, uses less memory, has a smaller binary.
Costs: rustc takes longer to build.

- [x] Linux x64: #115554, merged 2023-10-01.
- [x] Linux AArch64
- [x] Win64: #112267, merged 2024-03-12.
- [x] Mac: 
    - [x] intel: #112268, merged 2024-03-12.
    - [x] aarch64: #133747, merged 2024-12-03.

### PGO

Benefits: rustc is faster.
Costs: rustc takes longer to build.

- [x] Linux x64: #80262, merged 2020-12-23.
- [x] Linux AArch64: #133807
- [x] Win64 [2022]: #96978, merged 2022-07-12.
- [ ] Mac [2022]:
  - Problems with symbols not being matched correctly in PGO profiles.

Other PGO attempts:

- [ ] Call-site aware PGO for LLVM: #111806, no speed-up measured, seems like its benefits are superseded by BOLT.
- [ ] PGO for `libstd`: #97038, no speed-up measured.

### LTO

Benefits: rustc is faster.
Costs: rustc takes longer to build.

- Linux x64:
  - [x] rustc front-end: #101403, merged 2022-10-24.
  - [x] LLVM: done some time ago.
- [x] Linux AArch64: #133807 
- Win64:
  - [ ] rustc front-end: #103591, merged 2022-12-11. Caused a [miscompilation ](https://github.com/rust-lang/rust/issues/109067) and was reverted on 2023-03-14.
  - [ ] LLVM [2022]: currently statically linked, which prevents LTO, but this could be changed
- Mac:
  - [x] rustc front-end: #103647 and #105845, merged 2022-12-19.
  - [ ] LLVM [2022]: currently statically linked.

This is all thin LTO, which gets most of the benefits of fat LTO with a much lower link-time cost.

Other LTO attempts:
- [ ] LTO for `rustdoc`: #102885, no speed-up measured.
- [ ] Fat LTO: #103453, no speed-up measured, large CI build cost.

### BOLT

Benefits: rustc is faster.
Costs: rustc takes longer to build.

- Linux x64:
  - [x] rustc front-end: #116352, merged 2023-10-14.
  - [x] LLVM: #94381, merged 2022-10-10.
- [ ] Linux AArch64: waiting for BOLT bugs to be fixed on ARM 
- Win64: N/A
- Mac: N/A

Bolt only works on ELF binaries, and thus is Linux-only.

### Instruction set

Benefits: rustc is faster?
Costs: rustc won't run on old CPUs.

- [ ] x86_64: Update to v2/v3/APX sometime in the future. So far, the perf. wins haven't been convincing enough to upgrade, because it will reduce compatibility for older CPUs. Some perf. results can be found [here](https://github.com/rust-lang/rust/pull/95302).

### Linker

Benefits: rustc (linking) is faster.
Costs: hard to get working.

- using `lld` by default on `x86_64-unknown-linux-gnu`: 
    - [x] on nightly: #124129, merged 2024-05-17
    - [ ] on stable

### Better allocator

Benefits: rustc (linking) is faster.
Costs: rustc uses more memory?

- [x] Linux64: jemalloc, done some time ago.
- [ ] Win64 [2022]
- [x] Mac: jemalloc, done some time ago.

Note: #92249 and #92317 tried using two different versions of mimalloc (one 1.7-based, one 2.0-based) instead of jemalloc, but the speed/memory tradeoffs in both cases were deemed inferior (the max-rss regressions expected to be fixed in the 2.x series still exist as of 2.0.6, see #103944).

Note: we use a better allocator by simply overriding malloc/free, rather than using `#[global_allocator]`. See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Using.20.60.23.5Bglobal_allocator.5D.60.20for.20jemalloc.20on.20macOS.20.28w.2F.20data.29/near/294375737) for some discussion about the sub-optimality of this.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.