-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Sink unused const assignments #106613
Sink unused const assignments #106613
Conversation
r? @oli-obk (rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
@@ -28,7 +28,7 @@ pub struct ConstGoto; | |||
|
|||
impl<'tcx> MirPass<'tcx> for ConstGoto { | |||
fn is_enabled(&self, sess: &rustc_session::Session) -> bool { | |||
sess.mir_opt_level() >= 4 | |||
sess.mir_opt_level() >= 2 |
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.
It seems like DelayConstAssignments + ConstProp + SimplifyCfg ought to be able to handle everything that ConstGoto used to. (Which would be good, because those optimizations are more general than ConstGoto.)
e.g. for the simple example in ConstGoto's header:
bb2: {
_2 = const true;
goto -> bb3;
}
bb3: {
switchInt(_2) -> [false: bb4, otherwise: bb5];
}
I'd expect DelayConstAssignments to change it to
bb2: {
goto -> bb3;
}
bb3: {
_2 = const true;
switchInt(_2) -> [false: bb4, otherwise: bb5];
}
which ConstProp/SimplifyCfg should be able to handle.
Do you know of any situations where this doesn't work?
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.
In case it's not obvious I have no formal training or education of any kind in compilers or optimizations. I'm just looking through the MIR that comes out of the compiler today for things that look derpy and trying to fix them.
I think before ConstProp we can have code like this:
bb0: {
_8 = const 1;
_9 = const 2;
_10 = Add(move _8, _move 9);
switchInt(move _3) -> [0: bb1, 1: bb3, otherwise: bb2];
}
And here I am not sure the amount of analysis we'd need to figure out if _10 is being assigned a const is simpler than just doing ConstProp.
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.
Aside from the naming, it wasn't obvious. This pass is sensible :)
I may not have been clear--I think we should be able to remove ConstGoto (not ConstProp) after this change, because SinkConstAssignments should move the const assignment right into the block with the Ah, I thought ConstGoto was more limited than it is--it allows multiple predecessors, so it can't be replaced like that. This is fine as-is then. (FWIW, the optimization that ConstGoto performs is referred to elsewhere as jump threading.)switchInt
, which ConstProp/SimplifyCfg can handle without ConstGoto. Can you try your motivating Option::map
example without ConstGoto, and see if it still gets optimized?
It's a bit unfortunate that DataflowConstProp doesn't help here. It would know the value of the constant in the predecessor block, but there aren't any usages in the predecessor, so it doesn't do anything that would help ConstGoto. Maybe if it was available to other passes as an analysis...
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
let block_data = &body.basic_blocks[block]; | ||
let Some(terminator) = &block_data.terminator else { continue; }; | ||
|
||
let mut successors = Vec::new(); |
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.
Perhaps this should bail out when there are too many successors. It's probably not worth creating 100 new assign statements for a 100-arm match
539d00c
to
c7d9505
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #107309) made this pull request unmergeable. Please resolve the merge conflicts. |
72f54b6
to
c445d7e
Compare
This comment has been minimized.
This comment has been minimized.
80a7213
to
118865f
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 118865fb355b6535d79d52d806c3ccfb396b7ee9 with merge 90673fadd0ffde09dfdff3444aeaea5eb51b2281... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (90673fadd0ffde09dfdff3444aeaea5eb51b2281): comparison URL. Overall result: ❌✅ regressions and improvements - 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (f1f15ac48700d773dd71238c8f152c29dffc8b82): comparison URL. Overall result: ❌✅ regressions and improvements - 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit ac7531b7435eb8fe6b5adc29590de1b3d43a7f52 with merge 90c99bf540820d70bcb15c5c75996422aaa3ec35... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (90c99bf540820d70bcb15c5c75996422aaa3ec35): comparison URL. Overall result: ❌ regressions - 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
|
☔ The latest upstream changes (presumably #106908) made this pull request unmergeable. Please resolve the merge conflicts. |
@rustbot author |
a171f45
to
8396fc3
Compare
I'm planning on waiting for #107009 to land before evaluating the value of landing this |
8396fc3
to
0fc3e10
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #102906) made this pull request unmergeable. Please resolve the merge conflicts. |
Per the PR description, the jump threading pass has landed and since it produces the optimizations I was looking for with this pass, I'm closing this. |
Waiting for #107009 to land before re-evaluating the impact of this pass
This MIR optimization is designed to optimize away the drop flags in
Option::map
. It is based on the observation that there are actually two distinct code paths throughOption::map
, one forOption::None
and the other forOption::Some
, and along each of those code paths the drop flag is a constant assigned once to a local then branched on, but ConstGoto doesn't eliminate the branches because the assignments to the drop flag local don't occur in the branch immediately before the branch.So this optimization pushes the assignments later so that when possible they appear immediately before they are branched on, and ConstGoto is able to eliminate them.
A totally viable alternative approach would be making ConstGoto smarter. But I personally find viewing this whole situation from the perspective of the SwitchInt looking backwards complicated. Worded this way, a poor version of this implementation can be implemented in a single pass over the Body which should mitigate any runaway runtime.
cc @JakobDegen I think this is the 2 funclets ICEICE has been fixed