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.

[rust-bors]

☀️ Try build successful (CI)
Build commit: f2c5241 (f2c52417f03d127d4ac0c597a08cc54bc0c512af, parent: 3e353d7353b0cd6fa4eefd5c882457cc2708184c)

[rust-timer]

Finished benchmarking commit (f2c5241): 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.4%	[0.2%, 0.6%]	10
Regressions ❌ (secondary)	0.4%	[0.0%, 1.0%]	14
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	0.4%	[0.2%, 0.6%]	10

Max RSS (memory usage)

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

Cycles

Results (primary 4.0%, secondary -4.4%)

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

	mean	range	count
Regressions ❌ (primary)	4.0%	[4.0%, 4.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.4%	[-4.4%, -4.4%]	1
All ❌✅ (primary)	4.0%	[4.0%, 4.0%]	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
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	9
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	16
All ❌✅ (primary)	-0.0%	[-0.1%, -0.0%]	9

Bootstrap: 497.449s -> 499.206s (0.35%)
Artifact size: 397.06 MiB -> 395.02 MiB (-0.51%)

[bjorn3]

Forgot to update cc back to a version with the perf regression.

@bors try @rust-timer queue

[rust-bors]

💔 Test for eb2d6cd failed: CI. Failed job:

• try - dist-x86_64-linux-quick (web logs, enhanced plaintext logs)

[bjorn3]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: c698f04 (c698f04acda1165af3c450c98f7d0d6d8e7a9816, parent: 8068e2fc9afa8c888336b12db01987be768785f9)

[rust-timer]

Finished benchmarking commit (c698f04): 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.3%, 3.4%]	236
Regressions ❌ (secondary)	0.9%	[0.0%, 2.8%]	281
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.3%, 3.4%]	236

Max RSS (memory usage)

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

Cycles

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

Binary size

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

Bootstrap: 498.048s -> 499.972s (0.39%)
Artifact size: 397.10 MiB -> 396.63 MiB (-0.12%)

[thomcc]

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

Unless I'm mistaken, .flag_if_supported("-flto") will only work where we're directly using cc, which is not everywhere in the build (for example, as mentioned, it doesn't cover jemalloc).

Previously, any dependency of ours that was using cc would automatically get -flto when -Clto was passed, but that's not the case anymore (I'm not sure I think that was a good change, although I do understand the logic).

I think the most straightforward way to get this back is possibly to pass -flto via CFLAGS and CXXFLAGS in the environment, as the cc will pick things up specified that way automatically.

That said, doing so could have the side effect of turning on LTO for other parts of the build (as most systems that build C will pick these up, even if they don't parse/translate rustflags, which most don't), which may be a good thing, but also could cause further problems.

[bjorn3]

The code I modified is the code that determines the CFLAGS and CXXFLAGS env vars that will be passed to cargo build.