-
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
[WIP] [MIR] Generic lattice-based dataflow framework, rebased #34164
Conversation
Only a forward one so far
ACS here stands for Alias-Constant-Simplify. This propagation pass is a composition of three distinct dataflow passes: alias-propagation, constant-propagation and terminator simplification. This pass also serves to showcase the features of the framework. Most notably the terseness, composability and the capability to interleave analysis and transformations.
…value instead of by type
…ltiple statements
…tching the rest of rustc
…te to a projected lvalue, or through the destination of a call. Projected lvalues are now entirely not tracked. With --enable-orbit, everything bootstraps except for denied warnings.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Aatch (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Also, mutable updates of original block are somewhat incompatible with my plans to make it possible to replace any statement with an arbitrary subgraph, which is why I used to create a new block and then swap in the first place. |
I don't think mutable updates are necessarily incompatible with replacement by an arbitrary subgraph - the design I was envisioning was for the |
Note that although Travis passed, the debuginfo tests, which Travis skips, failed locally. |
☔ The latest upstream changes (presumably #33989) made this pull request unmergeable. Please resolve the merge conflicts. |
|
||
struct AcsPropagateTransfer; | ||
|
||
fn base_lvalue<'a, 'tcx>(mut lval: &'a Lvalue<'tcx>) -> &'a Lvalue<'tcx> { |
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'd be reasonable to just add this as a method on Lvalue
since other transformations will almost certainly find it useful as well.
Does this effectively implement part of #32966? |
@pcwalton yes. |
@gereeter I’m essentially done with my schoolwork now so I’ll be fetching your PR and begin working onto it. Thanks for your contribution! |
@@ -72,11 +72,11 @@ fn retain_basic_blocks(mir: &mut Mir, keep: &BitVector) { | |||
if alive_index != used_blocks { | |||
// Swap the next alive block data with the current available slot. Since alive_index is | |||
// non-decreasing this is a valid operation. | |||
mir.basic_blocks.swap(alive_index, used_blocks); | |||
mir.cfg.basic_blocks.swap(alive_index, used_blocks); |
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 prefer having RemoveDeadBlocks
being a "GC" pass and doing the swapping "manually", with other passes not removing BBs.
@nagisa @gereeter what is status of this PR, and which optimizations does it implement? I haven't had a chance to look at it yet (I admit, I was kind of waiting until @nagisa was around again, just because of lack of time...) but I'd like to try and do so now (though I'm also sort of on vacation -- trying to at least keep up with PRs though). But I see some comments suggesting that @nagisa may be opening another version? |
My own most up-to-date branch is here. It is based on this PR, so if you’re looking at anything, my suggestion is to look at that.
This PR cannot be merged as is. It does not differ very much from what I envision the thing will become in the end, though, so it certainly should be fine to do a shallow review to get familiar with the approach if there’s a desire to do so. My goal is to have forward move propagation and constant propagation passes implemented as a showcase of the framework (@greeter spent a lot of time making sure they are correct). This PR has those two passes implemented, but they still don’t quite work (or shouldn’t work) due to missing cleanup (liveness pass) and speculative analysis support (what @arielb1 noticed was missing during their review of the PR). Ultimately, given this cannot be merged, is out of date and is way past the request-for-comments date (since I’m actively working on it again), I suggest to close this PR. |
OK. |
This is a rebased and extended version of @nagisa's #33628. It could still do with at least cleanup and optimization, and there are extensions and changes that @nagisa has planned and that I have planned. However, I believe that I have fixed any bugs it causes, and this version successfully bootstraps locally.