Skip to content

Conversation

@moulins
Copy link
Contributor

@moulins moulins commented Dec 17, 2025

All usages of memory_index start by calling invert_bijective_mapping, so storing the inverted mapping directly saves some work and simplifies the code.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 17, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 17, 2025

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

@rustbot
Copy link
Collaborator

rustbot commented Dec 17, 2025

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

@rust-log-analyzer

This comment has been minimized.

@moulins moulins force-pushed the layout-inv-memory-index branch from c3ca7dc to 8db435e Compare December 18, 2025 00:12
@workingjubilee
Copy link
Member

huh. I wonder what it's inverted relative to?

@rust-log-analyzer

This comment has been minimized.

@workingjubilee
Copy link
Member

@moulins I have no objection to the substance of the change but "inverse" suggests a relativeness this doesn't capture... IMO this is still just a "memory index" until you do something like specify the other half of the pair, whether it's the key or value, at which point they might adopt a logical ordering.

mem_src_field_index maybe? idk.

@workingjubilee
Copy link
Member

kinda curious if this has any effect on perf or if it's just logical cleanup

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Dec 18, 2025
layout: Store inverse memory index in `FieldsShape::Arbitrary`
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 18, 2025
@moulins
Copy link
Contributor Author

moulins commented Dec 18, 2025

I have no objection to the substance of the change but "inverse" suggests a relativeness this doesn't capture... IMO this is still just a "memory index" until you do something like specify the other half of the pair, whether it's the key or value, at which point they might adopt a logical ordering.

mem_src_field_index maybe? idk

Hm, good point... what about in_memory_order?

@workingjubilee
Copy link
Member

something like that sounds good to me!

@rust-bors
Copy link

rust-bors bot commented Dec 18, 2025

☀️ Try build successful (CI)
Build commit: ed52dc8 (ed52dc8f27781eef22c18d699984ef94c758cc92, parent: f794a08738958bbef01c3dcab34ec21d3da1e51a)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (ed52dc8): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@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
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.1% [-0.2%, -0.0%] 2
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 1.8%)

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

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

Cycles

Results (primary 2.3%)

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

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

Binary size

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

Bootstrap: 481.694s -> 485.432s (0.78%)
Artifact size: 390.59 MiB -> 390.53 MiB (-0.01%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 18, 2025
FieldsShape::Arbitrary { memory_index, .. } => {
for idx in Self::aggregate_field_iter(memory_index) {
FieldsShape::Arbitrary { inverse_memory_index, .. } => {
for idx in Self::aggregate_field_iter(inverse_memory_index) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If iterating in memory order is now cheap, maybe we should just always do that... in fact that could unlock a bunch of follow-up cleanup here. Probably best to make all that a follow-up PR, but a good indication that this PR moves us in the right direction. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you'd propose removing aggregate_field_iter entirely and and simply iterate the fields directly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. But I would suggest doing it in a separate PR so we can separately benchmark that change.

@moulins moulins force-pushed the layout-inv-memory-index branch from 8db435e to e0bc269 Compare December 18, 2025 14:11
@rustbot

This comment has been minimized.

@moulins
Copy link
Contributor Author

moulins commented Dec 18, 2025

Renamed inverse_memory_index to in_memory_order, and updated some UI tests that I missed previously.

EDIT: I just noticed that rust-analyzer has its own version of FieldsShape, should I perform the same change here too?

@workingjubilee
Copy link
Member

@moulins I don't think this type is related in a meaningful way? https://github.com/rust-lang/rust/blob/main/src/tools/rust-analyzer/crates/hir-def/src/item_tree.rs#L519

Do you mean something else?

@workingjubilee
Copy link
Member

To be clear, I am 100% certain that rust-analyzer uses rustc_abi::FieldsShape also but have no idea what uses need to be changed if any.

@moulins
Copy link
Contributor Author

moulins commented Dec 18, 2025

You're totally right; from what I can see, the uses are here in Layout::{tail_padding, largest_padding}, but for some reason my ./x check still succeeds and trying to rename these uses causes an error.

All usages of `memory_index` start by calling `invert_bijective_mapping`, so
storing the inverted mapping directly saves some work and simplifies the code.
@moulins moulins force-pushed the layout-inv-memory-index branch from e0bc269 to b31ee3a Compare December 18, 2025 21:26
@rustbot
Copy link
Collaborator

rustbot commented Dec 18, 2025

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

@rustbot
Copy link
Collaborator

rustbot commented Dec 18, 2025

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@workingjubilee
Copy link
Member

Cool!

r? workingjubilee
@bors r+ rollup

( I don't believe this is truly performance sensitive by itself, I only asked the bot because it was truly just idle curiosity and I'm trying to get a sense of where the hotter spots in rustc_abi actually are (since they're effectively only realized at usage sites). )

@bors
Copy link
Collaborator

bors commented Dec 19, 2025

📌 Commit b31ee3a has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 19, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 19, 2025
…=workingjubilee

layout: Store inverse memory index in `FieldsShape::Arbitrary`

All usages of `memory_index` start by calling `invert_bijective_mapping`, so storing the inverted mapping directly saves some work and simplifies the code.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 19, 2025
…=workingjubilee

layout: Store inverse memory index in `FieldsShape::Arbitrary`

All usages of `memory_index` start by calling `invert_bijective_mapping`, so storing the inverted mapping directly saves some work and simplifies the code.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 19, 2025
…=workingjubilee

layout: Store inverse memory index in `FieldsShape::Arbitrary`

All usages of `memory_index` start by calling `invert_bijective_mapping`, so storing the inverted mapping directly saves some work and simplifies the code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants