Make DefId repr(C), optimize big-endian field order

[llogiq]

r? @michaelwoerister

[jackh726]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 95a3e6adc5e724e93a62915b22380b6137be08db with merge 6de93a5f3c58289159da3d736b0361ca414bd34f...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6de93a5f3c58289159da3d736b0361ca414bd34f (6de93a5f3c58289159da3d736b0361ca414bd34f)

[rust-timer]

Queued 6de93a5f3c58289159da3d736b0361ca414bd34f with parent 5531927, future comparison URL.

[rust-timer]

Finished benchmarking commit (6de93a5f3c58289159da3d736b0361ca414bd34f): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

• Very large improvement in instruction counts (up to -6.8% on incr-unchanged builds of ctfe-stress-4)
• Large regression in instruction counts (up to 3.5% on incr-unchanged builds of unicode_normalization)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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-review -S-waiting-on-perf +perf-regression

[llogiq]

That's weird. Even if I did something wrong, it shouldn't change the outcome by that much.

[michaelwoerister]

Yeah, that is weird. We'd expect the outcome to not change at all...

[jackh726]

I wonder if something is going wrong with perf: #91672 (comment)

[llogiq]

Yeah, that looks really fishy. Perhaps someone with access to perf can have a look?

[llogiq]

Ah it's likely because of rust-lang/rustc-perf#1123

[Mark-Simulacrum]

@bors retry @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 95a3e6adc5e724e93a62915b22380b6137be08db with merge 6a6e67427da0929979dc434855e205efe90bd2a3...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6a6e67427da0929979dc434855e205efe90bd2a3 (6a6e67427da0929979dc434855e205efe90bd2a3)

[rust-timer]

Queued 6a6e67427da0929979dc434855e205efe90bd2a3 with parent 7abab1e, future comparison URL.

[rust-timer]

Finished benchmarking commit (6a6e67427da0929979dc434855e205efe90bd2a3): comparison url.

Summary: This change led to moderate relevant regressions 😿 in compiler performance.

• Moderate regression in instruction counts (up to 3.2% on incr-patched: println builds of regression-31157)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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-review -S-waiting-on-perf +perf-regression

[llogiq]

So there is something wrong. I'll have a look.

[llogiq]

Can we get another perf run? I wonder if removing the repr(C) fixes the regression. Otherwise it must be because of the #[cfg(..)]s. I also wonder if at this point it would make sense to change DefId to a single u64 and make index and krate methods instead, but that change would be far larger. The upside would be that we could freely change the internal representation should we ever desire it.

[michaelwoerister]

perf.rlo seems to have problems with increased noise at the moment: rust-lang/rustc-perf#1126

Let's wait for that to be fixed and then revisit this.

[rust-timer]

Queued 586b3d2e1d80845457c6700c7e3deee19006521b with parent ddabe07, future comparison URL.

[rust-timer]

Finished benchmarking commit (586b3d2e1d80845457c6700c7e3deee19006521b): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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

[llogiq]

Ok, that's what we were expecting. Now I'll add the #[repr(C)] back.

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 7f7b551 with merge a5535ef48e9bb30104929abcdb9f1a6eec3d532f...

[bors]

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

[rust-timer]

Queued a5535ef48e9bb30104929abcdb9f1a6eec3d532f with parent 2b681ac, future comparison URL.

[rust-timer]

Finished benchmarking commit (a5535ef48e9bb30104929abcdb9f1a6eec3d532f): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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

[llogiq]

Cool. This means we haven't lost any perf on any tier-1 systems and may have gained a little on big-endian 64-bit machines, not that there would be a lot of them around.

[michaelwoerister]

Looks good now!
@bors r+

[bors]

📌 Commit 7f7b551 has been approved by michaelwoerister

[bors]

⌛ Testing commit 7f7b551 with merge e4b1d58...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing e4b1d58 to master...

[rust-timer]

Finished benchmarking commit (e4b1d58): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression