Ergonomic ref counting: optimize away clones when possible

[spastorino]

This PR build on top of #134797. It optimizes codegen of ergonomic ref-counting when the type being used is only known to be copy after monomorphization. We avoid codening a clone and generate bitwise copy instead.

RFC: rust-lang/rfcs#3680
Tracking issue: #132290
Project goal: rust-lang/goals#107

r? @nikomatsakis

This PR could better sit on top of #131650 but as it did not land yet I've decided to just do minimal changes. It may be the case that doing what I'm doing regress the performance and we may need to go the full route of #131650.
cc @saethlin in this regard.

[spastorino]

We need to clone the mir body here, unsure how bad this could be.

[spastorino]

Maybe in order to avoid affecting performance of things that do not involve use, we can just execute this when tcx.features().ergonomic_clones() is on.

[spastorino]

Would need to properly decide exactly what to do with this test. If just removing it is fine or if there's some variation that needs to be placed in tests/ui. Didn't bother to check this for now.

[rustbot]

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @vakaras

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[RalfJung]

(Procedurally, it'd be nice to reference the tracking issue in every PR related to that feature. Makes it much easier to navigate around for someone who's not following every single PR in this project.)

[rust-timer]

Finished benchmarking commit (aa03ab8): comparison URL.

Overall result: ❌ regressions - 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.2%	[0.2%, 0.3%]	3
Regressions ❌ (secondary)	0.3%	[0.2%, 0.6%]	20
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.2%, 0.3%]	3

Max RSS (memory usage)

Results (primary -0.4%, secondary -1.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.0%	[4.0%, 4.0%]	1
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	2
Improvements ✅ (primary)	-1.8%	[-2.7%, -0.5%]	3
Improvements ✅ (secondary)	-2.6%	[-3.8%, -2.0%]	6
All ❌✅ (primary)	-0.4%	[-2.7%, 4.0%]	4

Cycles

Results (secondary 1.8%)

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)	1.8%	[1.8%, 1.8%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 778.658s -> 780.235s (0.20%)
Artifact size: 366.00 MiB -> 365.98 MiB (-0.01%)

[nikomatsakis]

This seems like a good first option until #131650 lands. There are more efficient ways to do this if compilation time becomes an issue later on.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 4a0ea02 has been approved by nikomatsakis

It is now in the queue for this repository.

[spastorino]

Removed perf regression label as the latest perf run didn't show regressions. Anyway, we are keeping track of potential perf changes.

[Zalathar]

Scheduling: If the current rollup fails, move on to a never PR instead of an iffy PR.

@bors p=1

[bors]

⌛ Testing commit 4a0ea02 with merge 7d7de5b...

[bors]

☀️ Test successful - checks-actions
Approved by: nikomatsakis
Pushing 7d7de5b to master...

[github-actions]

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 9d28fe3 (parent) -> 7d7de5b (this PR)

Test differences

Show 10 test diffs

Stage 1

• [codegen] tests/codegen/ergonomic-clones/closure.rs: [missing] -> pass (J1)
• [crashes] tests/crashes/129372.rs: pass -> [missing] (J1)
• [mir-opt] tests/mir-opt/ergonomic-clones/closure.rs: [missing] -> pass (J1)

Stage 2

• [codegen] tests/codegen/ergonomic-clones/closure.rs: [missing] -> pass (J0)
• [crashes] tests/crashes/129372.rs: pass -> [missing] (J0)
• [mir-opt] tests/mir-opt/ergonomic-clones/closure.rs: [missing] -> pass (J0)

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

Job group index

• J0: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-1, x86_64-gnu, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-19-3

Job duration changes

1. dist-apple-various: 6377.4s -> 8558.3s (34.2%)
2. dist-x86_64-apple: 12204.8s -> 9057.1s (-25.8%)
3. aarch64-apple: 3464.1s -> 3993.0s (15.3%)
4. x86_64-gnu-nopt: 6506.5s -> 5556.9s (-14.6%)
5. dist-aarch64-apple: 4331.3s -> 4960.5s (14.5%)
6. dist-loongarch64-linux: 5924.9s -> 6381.1s (7.7%)
7. x86_64-gnu-aux: 5927.1s -> 6285.1s (6.0%)
8. x86_64-apple-1: 7968.7s -> 7565.1s (-5.1%)
9. dist-aarch64-linux: 5573.8s -> 5338.8s (-4.2%)
10. x86_64-msvc-ext2: 5959.5s -> 5708.9s (-4.2%)

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]

Finished benchmarking commit (7d7de5b): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -7.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
Improvements ✅ (secondary)	-7.3%	[-7.3%, -7.3%]	1
All ❌✅ (primary)	-	-	0

Cycles

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

Binary size

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

Bootstrap: 780.245s -> 782.463s (0.28%)
Artifact size: 366.19 MiB -> 366.23 MiB (0.01%)