-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Remove fewer Storage calls in copy_prop
#142531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Remove fewer Storage calls in copy_prop
#142531
Conversation
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.
…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%) |
@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.
…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%) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
2c919c0
to
48b0529
Compare
This comment has been minimized.
This comment has been minimized.
f282ae6
to
dcb58d1
Compare
This comment has been minimized.
This comment has been minimized.
dcb58d1
to
ad0ab67
Compare
This comment has been minimized.
This comment has been minimized.
ad0ab67
to
aa11a50
Compare
This comment has been minimized.
This comment has been minimized.
aa11a50
to
365edc7
Compare
365edc7
to
9beb9b6
Compare
Remove fewer Storage calls in GVN Followup to #142531 (Remove fewer Storage calls in `copy_prop`) Modify the GVN MIR optimization pass to remove fewer Storage{Live,Dead} calls, allowing for better optimizations by LLVM - see #141649. After replacing locals with values, use the `MaybeStorageDead` analysis to check that the replaced locals are storage-live. **A slight problem**: In #142531, `@tmiasko` noted #142531 (comment) that `MaybeStorageDead` isn't enough since there can be a `Live(_1); Dead(_1); Live(_1);` block which forces the optimization to check that each value is initialised (and not only storage-live). This is easy enough in `copy_prop` (because we are checking _before_ the replacement), but in GVN it is actually hard to tell for each statement if the local must be initialized or not after the fact (and modifying `VnState` seems even harder). I opted for something else which might be wrong (implemented in the last two commits): If we consider `Dead->Live` to be the same as `Deinit`, than such a local shouldn't be considered SSA - so I updated `SsaVisitor` to mark such cases as non-SSA. r? tmiasko
This comment has been minimized.
This comment has been minimized.
… to remove fewer storage statements
9beb9b6
to
6078a69
Compare
This comment has been minimized.
This comment has been minimized.
// To keep the storage of a head, we require that none of the locals in it's copy class are borrowed, | ||
// since otherwise we cannot easily identify when it is used. | ||
let mut storage_to_remove = ssa.borrowed_locals().clone(); | ||
storage_to_remove.intersect(&head_storage_to_check); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SsaLocals::borrowed_locals()[local]
describes whether local
is borrowed, not whether any local in its copy class is borrowed. An example that doesn't work as it supposed to:
#![feature(custom_mir, core_intrinsics, freeze)]
extern crate core;
use core::intrinsics::mir::*;
use core::marker::Freeze;
#[custom_mir(dialect = "runtime")]
pub fn f<T: Copy + Freeze>(_1: (T, T)) -> T {
mir! {
let _2: T;
let _3: T;
let _4: &T;
{
StorageLive(_2);
_2 = _1.0;
_3 = _2;
_4 = &_3;
StorageDead(_2);
RET = *_4;
Return()
}
}
}
$ rustc +stage1 b.rs --crate-type=lib -Zmir-opt-level=0 -Zmir-enable-passes=+CopyProp -Zunpretty=mir -Copt-level=1
fn f(_1: (T, T)) -> T {
let mut _0: T;
let mut _2: T;
let mut _3: T;
let mut _4: &T;
bb0: {
StorageLive(_2);
_2 = copy (_1.0: T);
_4 = &_2;
StorageDead(_2);
_0 = copy (*_4);
return;
}
}
I think it should be fine to allow the head itself to be borrowed (it is only all other locals from the copy class that cannot be borrowed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see, I read the compute_copy_classes
comment but assumed it referred to ssa.borrowed_locals()
, not the one it computes internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add this test and pushed the correct fix.
I do get reordered output for some tests (like tests/mir-opt/pre-codegen/derived_ord.rs
) and I'm not sure why, but the fixed impl now produces the correct output for this 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)
|
Modify the
copy_prop
MIR 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
thea newMaybeStorageDead
MaybeUninitializedLocals
analysis and remove only the storage calls ofhead
s that are maybe-uninit when the associatedlocal
is accessed (or, conversely, keep the storage ofhead
s that are for-sure initialized 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.