-
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
Fix constant propagation for scalar pairs #67015
Conversation
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
(fixed a long line) |
let scalar = if field_layout.details.size == Size::ZERO { | ||
Scalar::zst() | ||
} else { | ||
pair_values.pop().unwrap() |
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.
I think there might be a need for an additional check that the field actually
has Abi::Scalar
layout. Otherwise it could end up with an assignment between
Scalar
and ScalarPair
layouts, for example in something like test(((1, 2),))
,
when propagating the value of the outermost tuple.
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.
Amazing, your example uncovers another bug. I reported it as #67019.
I'll try to fix it in this PR too.
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.
Nice work overall!
Can you also check if this fixes #66339? |
It does not, but it changes the error. For actually fixing these both I think it'd be good to first decide whether we should be changing tuple reprs in const-prop (hence the Zulip topic). |
We definitely should not be doing that. |
OK, in that case I think this PR will change quite a bit and the final PR should fix both of these issues. I'm running out of time for today but I'll try to update sometime later this week. I hope this is not blocking anyone? |
@osa1 Sorry, my point was supposed to be that I think your PR is overall the right direction to go in. I think there's probably a few small tweaks you should make per the above feedback and then we can land this. |
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.
r? @wesleywiser |
The build is failing due to tidy:
|
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I'd be happy with either but I wonder if we should be including MIRs just yet because as far as I understand from the Zulip discussion we want to optimize scalar pairs more aggressively in the future so MIRs for these tests are currently not final. Same goes for the test for #66971 too actually. Opinions? |
Well... in that case you can just move the tests to |
Yes, that's what @wesleywiser suggested also. I'm just asking whether I should do that, or include current MIRs and keep the tests in current location. |
Let's add the MIRs. I'll update. |
⌛ Testing commit 2404a06 with merge 59264e56504466ca5619b0918148e828c6aa61c9... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
I'm completely unfamiliar with this part of the CI process. It looks like we're testing various crates from the ecosystem and one of the
|
@bors retry This PR makes an optimization less aggressive, I don't see how it could be causing this new failure |
Fix constant propagation for scalar pairs We now only propagate a scalar pair if the Rvalue is a tuple with two scalars. This for example avoids propagating a (u8, u8) value when Rvalue has type `((), u8, u8)` (see the regression test). While this is a correct thing to do, implementation is tricky and will be done later. Fixes rust-lang#66971 Fixes rust-lang#66339 Fixes rust-lang#67019
Rollup of 6 pull requests Successful merges: - #66881 (Optimize Ord trait implementation for bool) - #67015 (Fix constant propagation for scalar pairs) - #67074 (Add options to --extern flag.) - #67164 (Ensure that panicking in constants eventually errors) - #67174 (Remove `checked_add` in `Layout::repeat`) - #67205 (Make `publish_toolstate.sh` executable) Failed merges: r? @ghost
So that was an intermittent (non-deterministic?) test failure? I guess every project has them 😅 |
Did we never run perf on this? My guess is that this regression was caused by this PR. (EDIT: probably not, see below) |
We didn't but I'm not sure this PR is responsible because there are so many check regressions. When we turned on const prop by default, we only really saw improvements on debug & release builds not check builds because check builds don't query for optimized mir. |
… r=oli-obk Const prop should finish propagation into user defined variables Fixes rust-lang#66638 ~~Temporarily rebased on top of rust-lang#67015 to get those fixes.~~ r? @oli-obk
… r=oli-obk Const prop should finish propagation into user defined variables Fixes rust-lang#66638 ~~Temporarily rebased on top of rust-lang#67015 to get those fixes.~~ r? @oli-obk
Always const-prop scalars and scalar pairs This removes some complexity from the pass. The limitation to propagate ScalarPairs only for tuple comes from rust-lang#67015, when ScalarPair constant were modeled using `Rvalue::Aggregate`. Nowadays, we use `ConstValue::ByRef`, which does not care about the underlying type. The justification for not propagating in all cases was perf. This seems not to be a clear cut any more: rust-lang#113858 (comment)
We now only propagate a scalar pair if the Rvalue is a tuple with two scalars. This for example avoids propagating a (u8, u8) value when Rvalue has type
((), u8, u8)
(see the regression test). While this is a correct thing to do, implementation is tricky and will be done later.Fixes #66971
Fixes #66339
Fixes #67019