Remove fewer Storage calls in copy_prop
#142531
Open
+467
−29
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
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
bors
added a commit
that referenced
this pull request
Jun 15, 2025
…try>
Remove fewer Storage calls in `copy_prop`
Modify the `copy_prop` MIR optimization pass to remove fewer `Storage{Live,Dead}` calls, allowing for better optimizations by LLVM - see #141649.
### Details
This is my attempt to fix the mentioned issue (this is the first part, I also implemented a similar solution for GVN in [this branch](https://github.com/rust-lang/rust/compare/master...ohadravid:rust:better-storage-calls-gvn-v2?expand=1)).
The idea is to use the `MaybeStorageDead` analysis and remove only the storage calls of `head`s that are maybe-storage-dead when the associated `local` is accessed (or, conversely, keep the storage of `head`s that are for-sure alive in _every_ relevant access).
When combined with the GVN change, the final example in the issue (#141649 (comment)) is optimized as expected by LLVM. I also measured the effect on a few functions in `rav1d` (where I originally saw the issue) and observed reduced stack usage in several of them.
This is my first attempt at working with MIR optimizations, so it's possible this isn't the right approach — but all tests pass, and the resulting diffs appear correct.
r? tmiasko
since he commented on the issue and pointed to these passes.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (ef7d206): comparison URL. Overall result: ❌ regressions - please read the text belowBenchmarking 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 @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.7%, secondary 3.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -0.6%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 757.399s -> 756.065s (-0.18%) |
rustbot
added
perf-regression
|
@matthiaskrgr - I updated the impl to stop re-checking once a head is found to be maybe-dead, which should be a bit better |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
bors
added a commit
that referenced
this pull request
Jun 15, 2025
…try>
Remove fewer Storage calls in `copy_prop`
Modify the `copy_prop` MIR optimization pass to remove fewer `Storage{Live,Dead}` calls, allowing for better optimizations by LLVM - see #141649.
### Details
This is my attempt to fix the mentioned issue (this is the first part, I also implemented a similar solution for GVN in [this branch](https://github.com/rust-lang/rust/compare/master...ohadravid:rust:better-storage-calls-gvn-v2?expand=1)).
The idea is to use the `MaybeStorageDead` analysis and remove only the storage calls of `head`s that are maybe-storage-dead when the associated `local` is accessed (or, conversely, keep the storage of `head`s that are for-sure alive in _every_ relevant access).
When combined with the GVN change, the final example in the issue (#141649 (comment)) is optimized as expected by LLVM. I also measured the effect on a few functions in `rav1d` (where I originally saw the issue) and observed reduced stack usage in several of them.
This is my first attempt at working with MIR optimizations, so it's possible this isn't the right approach — but all tests pass, and the resulting diffs appear correct.
r? tmiasko
since he commented on the issue and pointed to these passes.
|
Should this check happen in |
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
I'm not sure how to make this work: using Is there a different way to do this? |
|
Finished benchmarking commit (c0a2949): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking 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 @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.1%, secondary -1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 756.494s -> 757.685s (0.16%) |
rustbot
removed
the
S-waiting-on-perf
tmiasko
reviewed
Jun 15, 2025
| if self.head_storage_to_check.contains(head) { | ||
| self.maybe_storage_dead.seek_after_primary_effect(location); | ||
|
|
||
| if self.maybe_storage_dead.get().contains(head) { |
There was a problem hiding this comment.
Storage liveness is not quite sufficient to identify locations where the definition can be used. Consider the following, where _2 becomes uninitialized after executing StorageDead(_2) and StorageLive(_2):
#![feature(custom_mir, core_intrinsics)]
extern crate core;
use core::intrinsics::mir::*;
#[custom_mir(dialect = "runtime")]
pub fn f<T: Copy>(_1: T) -> T {
mir! {
let _2: T;
let _3: T;
{
StorageLive(_2);
Call(_2 = opaque(Move(_1)), ReturnTo(bb1), UnwindUnreachable())
}
bb1 = {
let _3 = Move(_2);
StorageDead(_2);
StorageLive(_2);
Call(RET = opaque(Move(_3)), ReturnTo(bb2), UnwindUnreachable())
}
bb2 = {
StorageDead(_2);
Return()
}
}
}
#[inline(never)]
fn opaque<T>(a: T) -> T { a }rustc +ef7d20666974f0dac45b03e051f2e283f9d9f090 a.rs --crate-type=lib -Zmir-opt-level=0 -Zmir-enable-passes=+CopyProp -Zunpretty=mir
// WARNING: This output format is intended for human consumers only
// and is subject to change without notice. Knock yourself out.
// HINT: See also -Z dump-mir for MIR at specific points during compilation.
fn f(_1: T) -> T {
let mut _0: T;
let mut _2: T;
let mut _3: T;
let mut _4: T;
bb0: {
StorageLive(_2);
_2 = opaque::<T>(move _1) -> [return: bb1, unwind unreachable];
}
bb1: {
StorageDead(_2);
StorageLive(_2);
_0 = opaque::<T>(move _2) -> [return: bb2, unwind unreachable];
}
bb2: {
StorageDead(_2);
return;
}
}There was a problem hiding this comment.
Added this as a new test and switched to using the MaybeUninitializedPlaces analysis (which also requires another pass - TautologicalMoveAssignmentRemover).
Do you think this is a good approach?
And thanks for taking the time to look into this and for writing the test 🙏
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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.
Modify the
copy_propMIR optimization pass to remove fewerStorage{Live,Dead}calls, allowing for better optimizations by LLVM - see #141649.Details
This is my attempt to fix the mentioned issue (this is the first part, I also implemented a similar solution for GVN in this branch).
The idea is to use the
MaybeStorageDeadanalysis and remove only the storage calls ofheads that are maybe-storage-dead when the associatedlocalis accessed (or, conversely, keep the storage ofheads that are for-sure alive in every relevant access).When combined with the GVN change, the final example in the issue (#141649 (comment)) is optimized as expected by LLVM. I also measured the effect on a few functions in
rav1d(where I originally saw the issue) and observed reduced stack usage in several of them.This is my first attempt at working with MIR optimizations, so it's possible this isn't the right approach — but all tests pass, and the resulting diffs appear correct.
r? tmiasko
since he commented on the issue and pointed to these passes.