Skip to content

Conversation

cjgillot
Copy link
Contributor

@cjgillot cjgillot commented Jun 22, 2025

Profiling JumpThreading reveals that a large part of the runtime happens constructing the place and value Map. This is unfortunate, as jump-threading may end up not even doing anything.

The cause for this large up-front cost is following: Map attempts to create a PlaceIndex for each place that may hold a relevant value. This means all places that appear in MIR, but also all places whose value is accessed by a projection of a copy of a larger place.

This PR refactors the creation of Map to happen on-demand: place and value indices are created when threading computation happens.

The up-front mode is still relevant for DataflowConstProp, so is not touched.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 22, 2025
@cjgillot
Copy link
Contributor Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 22, 2025
bors added a commit that referenced this pull request Jun 22, 2025
JumpThreading: compute place and value indices on-demand

Perf experiment

r? `@ghost`
@bors
Copy link
Collaborator

bors commented Jun 22, 2025

⌛ Trying commit ba3a8c5 with merge 1587bef...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Jun 22, 2025

☀️ Try build successful - checks-actions
Build commit: 1587bef (1587bef3b2c2aea88de9b552efbf7febe7cd5fc4)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1587bef): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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)
1.0% [0.7%, 1.3%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.3% [-1.4%, -0.1%] 142
Improvements ✅
(secondary)
-0.4% [-1.7%, -0.1%] 93
All ❌✅ (primary) -0.3% [-1.4%, 1.3%] 144

Max RSS (memory usage)

Results (primary 3.6%, secondary 2.0%)

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

mean range count
Regressions ❌
(primary)
3.6% [3.4%, 3.8%] 2
Regressions ❌
(secondary)
2.0% [2.0%, 2.0%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.6% [3.4%, 3.8%] 2

Cycles

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

Binary size

Results (primary -0.1%, secondary 0.1%)

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

mean range count
Regressions ❌
(primary)
0.2% [0.0%, 0.4%] 12
Regressions ❌
(secondary)
0.2% [0.0%, 0.4%] 42
Improvements ✅
(primary)
-0.3% [-1.4%, -0.0%] 20
Improvements ✅
(secondary)
-0.3% [-0.9%, -0.0%] 5
All ❌✅ (primary) -0.1% [-1.4%, 0.4%] 32

Bootstrap: 689.082s -> 684.233s (-0.70%)
Artifact size: 371.89 MiB -> 372.00 MiB (0.03%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jun 23, 2025
@rust-log-analyzer

This comment has been minimized.

@cjgillot cjgillot marked this pull request as ready for review June 23, 2025 09:47
@rustbot
Copy link
Collaborator

rustbot commented Jun 23, 2025

r? @eholk

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

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 23, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 23, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@cjgillot cjgillot added the A-mir-opt Area: MIR optimizations label Jun 23, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 23, 2025

Some changes occurred in coverage tests.

cc @Zalathar

@cjgillot
Copy link
Contributor Author

r? compiler

@rustbot rustbot assigned oli-obk and unassigned eholk Jul 20, 2025
@cjgillot cjgillot force-pushed the minimap branch 2 times, most recently from d08b44c to f2018e5 Compare July 26, 2025 01:22
@bors
Copy link
Collaborator

bors commented Jul 28, 2025

☔ The latest upstream changes (presumably #144469) made this pull request unmergeable. Please resolve the merge conflicts.

@fee1-dead
Copy link
Member

r? oli-obk

@rustbot rustbot assigned oli-obk and unassigned fee1-dead Sep 1, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 1, 2025

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

@rustbot

This comment has been minimized.

@saethlin
Copy link
Member

r? saethlin

@rustbot rustbot assigned saethlin and unassigned oli-obk Sep 18, 2025
@saethlin
Copy link
Member

The PR description sounds like this is just a perf change, but I see that some of the tests were perturbed. Do you know why?

@saethlin saethlin added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 20, 2025
@rustbot

This comment has been minimized.

// CHECK: [[tmp:_.*]] = copy [[c]];
// CHECK: [[eq:_.*]] = Eq(move [[tmp]], const 2_i32);
// CHECK: switchInt(move [[eq]]) -> [0: bb2, otherwise: bb1];
// CHECK: goto -> bb1;
Copy link
Contributor Author

@cjgillot cjgillot Sep 21, 2025

Choose a reason for hiding this comment

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

Thanks @saethlin for pushing me to investigate this. One of the behaviour changes is a bugfix for this pattern. On master, if we read a twice, the b = a assignment makes us forget what the c = a assignment told us. With this PR, we correctly merge the sets of conditions.

@cjgillot
Copy link
Contributor Author

As for the other behaviour changes, my understanding is that this PR changes the order in which place and value indices are allocated. So changes where the MAX_PLACES cutoff happens.

@saethlin saethlin added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 26, 2025
@bors
Copy link
Collaborator

bors commented Sep 27, 2025

☔ The latest upstream changes (presumably #146829) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Oct 4, 2025

This PR was rebased onto a different master 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-mir-opt Area: MIR optimizations perf-regression Performance regression. 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.