shared-generics: Do not share instantiations that contain local-only types

[osiewicz]

In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet:

pub fn some_generic_function(_: impl Fn()) {}

pub fn non_generic_function() {
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
}

even though none of these instantiations can actually be created from outside of non_generic_function. This is a dummy example, but we do rely on invoking callbacks with FnOnce a lot in our codebase.

This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate.

This PR reduces incremental build time for Zed (touch editor.rs scenario) from 12.4s to 10.4s. I'd love to see a perf run if possible; per my checks this PR does not incur new instantiations in downstream crates, so if there'd be perf regressions, I'd expect them to come from newly-introduced visibility checks.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
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

[workingjubilee]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 5dd1877 with merge 7aab6d7...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7aab6d7 (7aab6d75a473a4253c0a5d9140bfa84ff2496527)

[rust-timer]

Finished benchmarking commit (7aab6d7): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	1.4%	[0.2%, 5.7%]	24
Regressions ❌ (secondary)	1.6%	[1.2%, 2.1%]	2
Improvements ✅ (primary)	-0.3%	[-0.6%, -0.2%]	7
Improvements ✅ (secondary)	-0.9%	[-1.2%, -0.6%]	2
All ❌✅ (primary)	1.0%	[-0.6%, 5.7%]	31

Max RSS (memory usage)

Results (primary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.9%	[1.3%, 9.4%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.0%	[-7.8%, -0.6%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.4%	[-7.8%, 9.4%]	9

Cycles

Results (primary 2.6%, secondary -1.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.6%	[0.9%, 6.5%]	10
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.8%, -2.0%]	3
All ❌✅ (primary)	2.6%	[0.9%, 6.5%]	10

Binary size

Results (primary 0.8%, secondary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.1%	[0.0%, 11.7%]	60
Regressions ❌ (secondary)	0.8%	[0.8%, 0.8%]	3
Improvements ✅ (primary)	-0.2%	[-0.4%, -0.0%]	14
Improvements ✅ (secondary)	-0.3%	[-0.7%, -0.0%]	15
All ❌✅ (primary)	0.8%	[-0.4%, 11.7%]	74

Bootstrap: 774.645s -> 772.98s (-0.21%)
Artifact size: 364.97 MiB -> 364.98 MiB (0.00%)

[workingjubilee]

huh. that is wild. all over the place.

[workingjubilee]

I can't tell if the regressions are "directly doing more work in a hot path" or "sharing generics was positively impacting local-only things in some cases, too".

[osiewicz]

I wouldn't expect this change to affect linked artifact size (since it should only remove metadata that was redundant in the first place - thus it should not be codegened downstream); my hunch is that it's somehow stripping too many instantiations, which then requires instantiations in downstream crates. I'll take a look later in the day.

[Kobzol]

The metadata diff can be seen here.

For library crates, the Binary size/Linked artifact size is the size of the .rlib files. And since crate metadata is all green, but for the same crates binary size is red, it means that this PR reduced crate metadata, but in some cases severely increased compiled code size.

[osiewicz]

Thanks for the pointer @Kobzol ! I added dbgs! around upstream_monomorpization (to see when an upstream mono could not be found). In case of exa (which is one of the crates for which we detected instruction count regression) there are new instantiations taking place, so it is indeed the case that this PR changes the set of instantiated functions, which is obviously not right. It should change the size of metadata, but not size of compiled code.

[nnethercote]

@osiewicz: what's the status of this PR now? Are you going to make more changes?

[osiewicz]

@nnethercote I don't plan to make any more changes, no; I wonder what the result of a perf is after 24932d6 though. As far as I can tell, it removes discrepancies in instantiation sets for cranelift_codegen and exa. Locally it still takes a bit longer to build cranelift_codegen for me though.

[nnethercote]

@bors try @rust-timer queue

[osiewicz]

@rustbot ready

[bjorn3]

I think the overall approach is sound. I do think there are two changes that may improve performance a bit.

[osiewicz]

@rustbot ready

[bjorn3]

@bors try @rust-timer queue

r=me if there is no regression since the last perf run.

[bors]

⌛ Trying commit 870bc6a with merge d7249c331c9182e73fc9404ff8b40dbce4593918...

[osiewicz]

@bjorn3 FYI there was another perf run in the meantime.

[bors]

☀️ Try build successful - checks-actions
Build commit: d7249c3 (d7249c331c9182e73fc9404ff8b40dbce4593918)

[rust-timer]

Finished benchmarking commit (d7249c3): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.4%, 0.8%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-0.8%	[-0.9%, -0.7%]	2
All ❌✅ (primary)	0.2%	[-0.7%, 0.8%]	3

Max RSS (memory usage)

Results (primary 0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.4%, 2.0%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.8%, -0.5%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-0.8%, 2.0%]	10

Cycles

Results (primary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.6%, -0.4%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-0.6%, 0.4%]	4

Binary size

Results (primary -0.1%, secondary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.3%, -0.0%]	29
Improvements ✅ (secondary)	-0.3%	[-0.7%, -0.1%]	15
All ❌✅ (primary)	-0.1%	[-0.3%, -0.0%]	29

Bootstrap: 761.588s -> 761.224s (-0.05%)
Artifact size: 365.21 MiB -> 365.11 MiB (-0.03%)

[bjorn3]

Perf looks fine. Would you mind squashing your changes?