Add fast path for maybe-initializedness in liveness #141667
Merged
+67
−48
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This dataflow analysis is only used by `liveness::trace`. We move it there to make it lazy.
Only drop-liveness checks for maybe-initializedness of move paths, and it does so only for the relevant live locals that have drop points. This adds a fast path by computing this dataflow analysis only when checking for such initializedness. This avoids this expensive computation for the common case. For example, it avoids computing initializedness for 20K locals in the `cranelift-codegen` benchmark, it has 7K relevant live locals but none with drop points. That saves 900ms on end-to-end compilation times.
This mir-opt test used the maybe-init dataflow analysis but it's now lazy and doesn't emit the graphviz graph when it's not needed anymore.
rustbot
added
S-waiting-on-review
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
18 tasks
bors
added a commit
that referenced
this pull request
May 27, 2025
Add fast path for maybe-initializedness in liveness r? `@matthewjasper` Correct me if I'm wrong Matthew, but my understanding is that 1. `MaybeInitializedPlaces` is currently eagerly computed, in `do_mir_borrowck` 2. but this data is only used in liveness 3. and `liveness::trace` actually only uses it for drop-liveness This PR moves the computation to `liveness::trace` which looks to be its only use-site. We also add a fast path there, so that it's only computed by drop-liveness. This is interesting because 1) liveness is only computed for relevant live locals, 2) drop-liveness is only computed for relevant live locals with >0 drop points; 0 is the common case from our benchmarks, as far as I can tell, so even just computing the entire data lazily helps. It seems possible to also reduce the domain here, and speed up the analysis for the cases where it has to be computed -- so I've left a fixme for that, and may look into it soon. (I've come upon this while doing implementation work for polonius, so don't be too enamored with possible wins: the goal is to reduce the eventual polonius overhead and make it more palatable 😓)
bors
added a commit
that referenced
this pull request
May 27, 2025
Add fast path for maybe-initializedness in liveness r? `@matthewjasper` Correct me if I'm wrong Matthew, but my understanding is that 1. `MaybeInitializedPlaces` is currently eagerly computed, in `do_mir_borrowck` 2. but this data is only used in liveness 3. and `liveness::trace` actually only uses it for drop-liveness This PR moves the computation to `liveness::trace` which looks to be its only use-site. We also add a fast path there, so that it's only computed by drop-liveness. This is interesting because 1) liveness is only computed for relevant live locals, 2) drop-liveness is only computed for relevant live locals with >0 drop points; 0 is the common case from our benchmarks, as far as I can tell, so even just computing the entire data lazily helps. It seems possible to also reduce the domain here, and speed up the analysis for the cases where it has to be computed -- so I've left a fixme for that, and may look into it soon. (I've come upon this while doing implementation work for polonius, so don't be too enamored with possible wins: the goal is to reduce the eventual polonius overhead and make it more palatable 😓)
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (4027458): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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 may lead to changes in compiler perf. @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.4%, secondary 3.5%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -6.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 779.523s -> 778.77s (-0.10%) |
rustbot
removed
the
S-waiting-on-perf
|
@bors r+ |
bors
added
S-waiting-on-bors
tamird
reviewed
May 28, 2025
| /// initialized. | ||
| flow_inits: ResultsCursor<'a, 'tcx, MaybeInitializedPlaces<'a, 'tcx>>, | ||
| /// initialized. Computed lazily when needed by drop-liveness. | ||
| flow_inits: Option<ResultsCursor<'a, 'tcx, MaybeInitializedPlaces<'a, 'tcx>>>, |
There was a problem hiding this comment.
this could be a OnceCell and avoid the need for the few &mut selfs added in this commit.
https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html#method.get_or_try_init
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 7a7bcbb (parent) -> ec28ae9 (this PR) Test differencesShow 33421 test diffsStage 1
Stage 2
(and 16608 additional test diffs) Additionally, 16713 doctest diffs were found. These are ignored, as they are noisy. Job group index Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard ec28ae9454139023117270985f114823d6570657 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced May 31, 2025
|
Finished benchmarking commit (ec28ae9): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -3.6%, secondary 1.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -5.0%, secondary -0.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 778.793s -> 776.684s (-0.27%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? @matthewjasper
Correct me if I'm wrong Matthew, but my understanding is that
MaybeInitializedPlacesis currently eagerly computed, indo_mir_borrowckliveness::traceactually only uses it for drop-livenessThis PR moves the computation to
liveness::tracewhich looks to be its only use-site. We also add a fast path there, so that it's only computed by drop-liveness.This is interesting because 1) liveness is only computed for relevant live locals, 2) drop-liveness is only computed for relevant live locals with >0 drop points; 0 is the common case from our benchmarks, as far as I can tell, so even just computing the entire data lazily helps.
It seems possible to also reduce the domain here, and speed up the analysis for the cases where it has to be computed -- so I've left a fixme for that, and may look into it soon.
(I've come upon this while doing implementation work for polonius, so don't be too enamored with possible wins: the goal is to reduce the eventual polonius overhead and make it more palatable 😓)