Skip to content
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

Closed
wants to merge 24 commits into from

Conversation

gereeter
Copy link
Contributor

@gereeter gereeter commented Jun 8, 2016

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.

nagisa and others added 20 commits June 6, 2016 19:29
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.
…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.
@rust-highfive
Copy link
Collaborator

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.

@nagisa
Copy link
Member

nagisa commented Jun 8, 2016

NB: CFG part of bb183e2 will not be necessary anymore once #34149 lands.

@nagisa
Copy link
Member

nagisa commented Jun 8, 2016

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.

@gereeter
Copy link
Contributor Author

gereeter commented Jun 8, 2016

I don't think mutable updates are necessarily incompatible with replacement by an arbitrary subgraph - the design I was envisioning was for the StatementChange variant to simply contain two basic blocks, an entry block and an exit block. The rewrite pass is responsible for creating any new blocks. In ar_forward, when this is seen, the tail of the current block is copied to the exit block, the current fact is recorded for the entry block, and a new Goto terminator is stuck on. This shouldn't confuse the fixpoint loop, as basic block numbers and meanings remain stable - it just has to be notified that there are new basic blocks.

@gereeter
Copy link
Contributor Author

gereeter commented Jun 8, 2016

Note that although Travis passed, the debuginfo tests, which Travis skips, failed locally.

@bors
Copy link
Contributor

bors commented Jun 8, 2016

☔ 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> {
Copy link
Member

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.

@pcwalton
Copy link
Contributor

Does this effectively implement part of #32966?

@nagisa
Copy link
Member

nagisa commented Jun 12, 2016

@pcwalton yes.

@nagisa
Copy link
Member

nagisa commented Jun 12, 2016

@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);
Copy link
Contributor

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.

@nikomatsakis
Copy link
Contributor

@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?

@nagisa
Copy link
Member

nagisa commented Jun 22, 2016

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.

what is status of this PR, and which optimizations does it implement?

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.

@nikomatsakis
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants