Various refactors to the LTO handling code (part 2)

[bjorn3]

Continuing from #143388 this removes a bit of dead code and moves the LTO symbol export calculation from individual backends to cg_ssa.

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[lcnr]

looked through all the commits and while they look good to me, I don't feel comfortable actually judging these changes, so

r? compiler

[antoyo]

What does this mean exactly?
Does that mean that only those symbols should be exported?

[bjorn3]

Yes. This is a superset of the set of symbols that will be exported by the linker (it also includes #[used] symbols to ensure those are kept by LTO). By already marking the rest as non-exported during LTO, LTO can optimize non-exported functions more aggressively. For example by changing their ABI or dropping them entirely if unused.

[bjorn3]

Since lcnr's review I've moved the checks for if LTO is allowed to happen right before LTO is done rather than when the coordinator thread starts. This way it doesn't happen for --emit metadata or for non-linked crate types.

Also give than this makes the symbol filtering always happen:

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit 02d63c0 with merge f1a7db9…

To cancel the try build, run the command @bors2 try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: f1a7db9 (f1a7db981fde509fe79c4358b40b84e4ca8d66ce, parent: bf5e6cc7a7a7eb03e3ed9b875d76530eddd47d5f)

[rust-timer]

Finished benchmarking commit (f1a7db9): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

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
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	[-6.8%, -1.2%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -5.0%, secondary 1.0%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.6%, 3.1%]	2
Improvements ✅ (primary)	-5.0%	[-6.8%, -3.7%]	3
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	-5.0%	[-6.8%, -3.7%]	3

Cycles

Results (secondary -1.2%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.1%, 2.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.7%	[-5.9%, -3.3%]	3
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 464.659s -> 464.118s (-0.12%)
Artifact size: 374.78 MiB -> 374.77 MiB (-0.00%)