Update the cc crate for rustc_llvm

[bjorn3]

View all comments

Latest stacker needs a newer cc than 1.2.16 as older versions don't have windows arm64ec support.

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

r? @Mark-Simulacrum

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Mark-Simulacrum

[bjorn3]

Given that the previous attempt regressed performance:

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: f61a781 (f61a781aa926b40af32168929f416c41f07e54b3, parent: 27dbdb57a2f90b5c90247e6ef14f2657a03473da)

[rust-timer]

Finished benchmarking commit (f61a781): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@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.7%	[0.4%, 3.4%]	247
Regressions ❌ (secondary)	0.9%	[0.0%, 2.7%]	289
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.4%, 3.4%]	247

Max RSS (memory usage)

Results (primary -0.0%, secondary 2.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.5%	[1.5%, 1.5%]	1
Regressions ❌ (secondary)	2.4%	[2.2%, 2.6%]	2
Improvements ✅ (primary)	-1.6%	[-1.6%, -1.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-1.6%, 1.5%]	2

Cycles

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

Binary size

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

Bootstrap: 490.301s -> 492.119s (0.37%)
Artifact size: 394.23 MiB -> 393.76 MiB (-0.12%)

[Mark-Simulacrum]

I think we need an explanation if not necessarily a solution (though those regressions look rather large, including on full builds).

@rustbot author

[ChrisDenton]

The nearest to an explanation seems to be #146186 (comment), cc @madsmtm

It would be a bit of a problem if we can never upgrade cc-rs again...

[madsmtm]

I never got further than that investigation unfortunately

[bjorn3]

I've ran cachegrind for stm32f4-0.15.1 and I'm now fairly certain that #146186 (comment) was correct about jemalloc being the cause of the slowdown. Cachegrind shows a lot more jemalloc functions after this PR, suggesting less inlining.

[bjorn3]

@bors try @rust-timer queue

[bjorn3]

Spurious CI failure.

@bors try @rust-timer queue

[bjorn3]

Oops, that was just a PR CI failure, not the try CI.

[rust-bors]

☀️ Try build successful (CI)
Build commit: cc1f7b3 (cc1f7b3dd0e8c08535673d2776754c156988abdf, parent: 2eaa5de4a3a911f52adbee7dda0bc84b06115576)

[rust-timer]

Finished benchmarking commit (cc1f7b3): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (secondary -2.5%)

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

Binary size

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

Bootstrap: 490.12s -> 490.282s (0.03%)
Artifact size: 394.30 MiB -> 394.36 MiB (0.01%)

[bjorn3]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 38101bc (38101bc911559b28d5bcb49afafd8e4b8c2a8b86, parent: fb76025f2fe6a1c8ce03fe0931f941c8077a2c34)

[rust-timer]

Finished benchmarking commit (38101bc): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (secondary 0.5%)

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)	6.0%	[5.9%, 6.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.1%	[-7.3%, -2.9%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 2.6%, secondary 2.6%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.6%, 2.6%]	1
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.6%	[2.6%, 2.6%]	1

Binary size

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

Bootstrap: 487.131s -> 488.722s (0.33%)
Artifact size: 394.07 MiB -> 394.03 MiB (-0.01%)

[bjorn3]

That bisects the regression to rust-lang/cc-rs@cc-v1.2.37...cc-v1.2.39. I'm pretty sure the regressing PR was rust-lang/cc-rs#1564 which causes LTO to only be used for C code when -Clinker-plugin-lto was passed to rustc. @NobodyXu as indicated by #155438 (comment) this caused a non-trivial performance regression for rustc as jemalloc no longer gets LTOed.

[NobodyXu]

Thanks for reporting!

We thought that translating -Clto to -flto was inappropriate as the linker might not support llvm bitcode

Maybe you can explicitly pass .flag_if_supported("-flto")?

[nikic]

FWIW, the jemalloc LTO is kind of annoying because it forces us to update the LLVM version by Rust and that of the host compiler in sync, otherwise we get this perf regression during LLVM updates.

[bjorn3]

I think we are only doing LTO within jemalloc itself (or maybe between jemalloc and LLVM), not between jemalloc and rust code given that we don't build rustc with -Clinker-plugin-lto.