Improve `Session`/`CodegenBackend` construction by nnethercote · Pull Request #161432 · rust-lang/rust

nnethercote · 2026-08-20T23:29:47Z

The creation and initialization of sessions and codegen backends is intertwined, which is confusing and error prone. This PR detangles things, and also simplifies the types used for the state within the backends. Details in individual commits.

r? @bjorn3

rustbot · 2026-08-20T23:29:51Z

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

nnethercote · 2026-08-20T23:30:36Z

This is an opinionated change, see what you all think.

LLM disclosure: some of the ideas came from an analysis done by an LLM. I wrote all the code and text myself.

antoyo · 2026-08-20T23:38:54Z

-    fn fmt(&self, formatter: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
-        self.info.lock().expect("lock").fmt(formatter)
-    }
+#[derive(Clone)]


Do the cg_gcc changes need to be done in this PR?
I would be more confortable landing this directly in the cg_gcc repo so that the whole test suite can run (some cg_gcc tests do not run here in the Rust repo).

View changes since the review

I think they do, because both commits change the signature of CodegenBackend::init. Doing a local test run in cg_gcc is probably the way forward, if/when there's agreement that this PR is worth merging.

RalfJung

Broadly makes sense to me but I did not check all the details.

View changes since this review

RalfJung · 2026-08-21T07:25:13Z

FWIW there is some more codegen-backend-related session initialization happening inside add_configuration. And especially the handing of target features is a complete mess (not as bad as it used to be, but still bad). We're calling llvm_util::global_llvm_features like half a dozen times because we need it in various places and we don't have a tcx yet so it can't be a query...

Anyway, not really something for this PR. I just wondered what this PR does with the messy part of codegen backend initialization that I regularly run into, and the answer is "nothing". Which is fine, the cleanup here seems reasonable on its own. Maybe inspiration for a future cleanup PR. :)

Interesting. I looked into add_configuration and found a bug; #161718 fixes it and takes a step towards cleaning things up more. Once that PR merges I will do more in this PR to fix the remaining ordering problems.

I also looked at global_llvm_features. There is a query for it, global_backend_features, but it's not actually necessary. It should be possible to get the features once and store them in the session, which should make things simpler. Not sure yet if I will do that in this PR or a follow-up.

I have successfully removed the global_backend_features query. #161903 needs to merge first.

Currently, `parse_cfg` calls `build_configuration`, which calls `default_configuration`, which calls `sess.target.singlethread(&sess.internal_target_features)`. But `sess.internal_target_features` hasn't been set at this point and is empty! This commit moves the setting of `sess.internal_target_features` before the `parse_cfg` call to fix this ordering bug. This results in the `cfg(target_has_threads)` being correctly set on `wasm32-unknown-unknown` when `-Ctarget-feature=+atomics` is specified. Note: I have plans to make this kind of ordering bug difficult/impossible in a follow-up (e.g. rust-lang#161432).

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating an `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating and `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

rustbot · 2026-08-31T04:57:10Z

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

These commits modify compiler targets.
(See the Target Tier Policy.)

`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating and `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.

nnethercote · 2026-09-15T21:32:09Z

@bors r=bjorn3

rust-bors · 2026-09-15T21:32:12Z

📌 Commit 2e88050 has been approved by bjorn3

It is now in the queue for this repository.

Session creation is currently awkward: we build a mostly-initialized session, then use it to initialize a codegen backend, and then use the codegen backend to finish initializing the session. And it's not just awkward: within the Cranelift backend's `init` method `sess.lto()` is called, which consults `sess.thin_lto_supported`, *before* that field has been properly set! In practice it had no effect but it's worth fixing. This commit cleans up this mess. It introduces `EarlySession`, which contains just four `Session` fields, the ones that are needed for codegen backend initialization. It is now a field within `Session`, and `Session` derefs to `EarlySession` to avoid changing a zillion `sess.target`/`sess.opts`/etc. occurrences. `EarlySession` is passed to `init`, which returns a `CodegenBackendInit` that contains the backend-specific information needed to build a `Session`. (It replaces the `replaced_intrinsics`, `fallback_intrinsics`, and `thin_lto_supported` methods.) The `Session` can then be built in a single step. No more `Session`/`CodegenBackend` initialization intermingling. A few functions that previously took a `Session` now take something else, e.g. a `Target`. Some `Session` methods are now `EarlySession` methods. And a new `early_lto` method is used for Cranelift's LTO check.

It currently takes `&self`, which is a bit strange for an `init` method. As a result, the Cranelift and GCC backends have to use types with interior mutability. This commit changes it to `&mut self`. Benefits: - The Cranelift backend can use `Option` instead of `OnceCell` to indicate uninit vs. init. - The GCC backend can avoid `Mutex`, and use `bool` instead of `AtomicBool`, which makes things much simpler. The commit also restructures `GccCodegenBackend` to mirror `CraneliftCodegenBackend`: just contain an `Option<BackendConfig>`, which makes the uninit vs. init distinction foolproof. (E.g. no need to set `lto_supported` to false and then later overwrite it with the real value.) As part of this the `LockedTargetInfo` type is renamed `SharedTargetInfo` because that better matches its new internals. (All this compiles both with and without the "master" feature set.)

It's now possible to get the backend features (a `Vec<String>`) when the codegen backend is started, pass it back through `CodegenBackendInit`, and just store it in the `Session`. This removes the need for the query. Also: - `WriteBackendMethods::target_machine_factory` no longer needs the `target_features` parameter, because it's now available through the `sess` parameter. - `CodegenContext` no longer needs the `backend_features` field because we can use `sess.global_backend_features` instead. - `CodegenBackend::provide` is now a no-op for all the in-tree backends. I haven't removed it because out-of-tree backends still rely on it.

rustbot · 2026-09-16T05:33:18Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

nnethercote · 2026-09-16T05:33:27Z

I rebased.

@bors r=bjorn3

rust-bors · 2026-09-16T05:33:30Z

📌 Commit 8515e12 has been approved by bjorn3

It is now in the queue for this repository.

rust-bors · 2026-09-16T14:24:02Z

☀️ Test successful - CI
Approved by: bjorn3
Duration: 3h 9m 58s
Pushing e15cecc to main...

github-actions · 2026-09-16T14:27:13Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 28e8a8c (parent) -> e15cecc (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard e15ceccfc6209c15b6c4bc6352f6ec6bfe579eaa --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

test-i686-gnu-nopt-2: 1h 30m -> 2h 39m (+76.9%)
test-x86_64-gnu-llvm-22-2: 1h 7m -> 1h 43m (+54.1%)
test-x86_64-gnu-nopt: 1h 36m -> 2h 28m (+53.8%)
test-x86_64-gnu-llvm-22-3: 1h 18m -> 1h 45m (+33.7%)
test-x86_64-gnu-llvm-22-1: 1h 2m -> 1h 23m (+33.1%)
test-x86_64-gnu-llvm-21-1: 47m 25s -> 1h 2m (+32.2%)
test-various: 2h 7m -> 1h 29m (-30.2%)
test-armhf-gnu: 1h 15m -> 1h 38m (+30.0%)
dist-apple-various: 1h 47m -> 2h 17m (+28.1%)
test-x86_64-gnu: 2h 4m -> 2h 39m (+27.8%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-09-16T15:08:39Z

Finished benchmarking commit (e15cecc): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	5
Regressions ❌ (secondary)	0.4%	[0.2%, 0.6%]	3
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.6%	[-0.8%, -0.4%]	8
All ❌✅ (primary)	0.1%	[-0.2%, 0.2%]	6

Max RSS (memory usage)

Results (primary 3.0%, secondary 0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.0%	[2.1%, 3.9%]	2
Regressions ❌ (secondary)	5.9%	[3.1%, 10.1%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.0%	[-5.4%, -1.0%]	8
All ❌✅ (primary)	3.0%	[2.1%, 3.9%]	2

Cycles

Results (primary 2.9%, secondary 2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	2.7%	[2.0%, 3.9%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.9%	[2.9%, 2.9%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 496.137s -> 494.504s (-0.33%)
Artifact size: 406.79 MiB -> 406.72 MiB (-0.02%)

rustbot assigned bjorn3 Aug 20, 2026

antoyo reviewed Aug 20, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

RalfJung reviewed Aug 21, 2026

View reviewed changes

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs Outdated

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/session.rs

bjorn3 reviewed Aug 21, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_cranelift/src/lib.rs Outdated

nnethercote mentioned this pull request Aug 25, 2026

Fix the wasm32-unknown-unknown target feature/cfg bug #161718

Merged

bjorn3 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2026

nnethercote force-pushed the improve-session-backend-building branch from 1225a52 to dacfcaa Compare August 31, 2026 04:57

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs T-clippy Relevant to the Clippy team. labels Aug 31, 2026

This comment has been minimized.

Sign in to view

nnethercote force-pushed the improve-session-backend-building branch from dacfcaa to c8f2df6 Compare August 31, 2026 05:08

This comment has been minimized.

Sign in to view

nnethercote added 3 commits September 16, 2026 15:29

nnethercote force-pushed the improve-session-backend-building branch from 2e88050 to 8515e12 Compare September 16, 2026 05:33

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 16, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 16, 2026

rust-bors Bot merged commit e15cecc into rust-lang:main Sep 16, 2026
14 checks passed

rustbot added this to the 1.100.0 milestone Sep 16, 2026

nnethercote deleted the improve-session-backend-building branch September 16, 2026 20:01

Uh oh!

Uh oh!

Conversation

nnethercote commented Aug 20, 2026 • edited by ada4a Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Aug 20, 2026

Uh oh!

nnethercote commented Aug 20, 2026

Uh oh!

antoyo Aug 20, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nnethercote Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Aug 25, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Aug 31, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nnethercote commented Sep 15, 2026

Uh oh!

rust-bors Bot commented Sep 15, 2026

Uh oh!

This comment has been minimized.

rustbot commented Sep 16, 2026

Uh oh!

nnethercote commented Sep 16, 2026

Uh oh!

rust-bors Bot commented Sep 16, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Sep 16, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 16, 2026

Test differences

Job duration changes

Uh oh!

rust-timer commented Sep 16, 2026

Overall result: ❌✅ regressions and improvements - please read:

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

nnethercote commented Aug 20, 2026 •

edited by ada4a

Loading

antoyo Aug 20, 2026 •

edited by rustbot

Loading

RalfJung left a comment •

edited by rustbot

Loading

nnethercote Aug 31, 2026 •

edited

Loading