[RFC-ish][MIR] Add a pass manager #31448
Conversation
nagisa
force-pushed
the
mir-tiered-passes
branch
2 times, most recently
from
665e9a0
to
530beae
Compare
nagisa
force-pushed
the
mir-tiered-passes
branch
2 times, most recently
from
c2cc646
to
b1d9e88
Compare
|
cc @rust-lang/compiler -- I'd be curious to get others' take here. |
|
I'm somewhat aghast that mir pass plugins have sneaked into the compiler with no discussion, I think that is a bit premature. Anyway, looking at this PR, I'm in favour of reducing the ad-hoc calling of passes, but this feels like unnecessary flexibility and complexity. |
|
|
||
| /// Pass which only inspects basic blocks in MIR. | ||
| /// | ||
| /// Invariant: The blocks are considered to be fully self-contained for the purposes of this pass – |
There was a problem hiding this comment.
Why do we need this invariant? For the MirPass implementor it's irrelevant, as it's the same as making sure that the visitor and the run_pass method don't modify the Mir object. For the compiler there's no advantage to knowing this as I see it.
I’ve modelled the passes to match the LLVM’s pass structure somewhat closely – namely their What I’m currently worried about the most, after sleeping on it for a while, is that the passes might not be flexible enough yet (for e.g. @arielb1’s typeck pass). |
|
On Tue, Feb 09, 2016 at 06:54:29PM -0800, Nick Cameron wrote:
I was also surprised. |
|
Are there any users for |
|
I mean, what would you use it for? |
|
@arielb1 I was initially considering it to be a good fit for:
The drop removal pass, however, would rely on passes being able to share the analysis results with other passes, namely the liveness checker. I think typeck pass could also use it, provided we happen to grow support for something similar to EDIT: to summarize, I, myself, think that in current state, the |
| } | ||
|
|
||
| /// Pass which only inspects MIR of distinct functions. | ||
| pub trait MirPass: Pass { |
There was a problem hiding this comment.
The 'tcx lifetime might be better on the trait itself.
|
I was kind-of working on an unnecessary drop removal as a part of non-zeroing drop, but I think that work is going to be stuck for a while. Of course, that would probably want to be a full function pass because of the dataflow/analysis. |
|
OK so I think these are my overall thoughts:
(It may be worth writing an RFC on this, but it also feels like overkill.) |
Only the pass hierarchy ( |
|
I’m fine with stripping this PR to a bare minimum so only the barebones pass manager (executes pass in order they’ve been pushed), |
Tiered passes allow to avoid some of the introspection of MIR map for passes which do not need it and perhaps improve performance of the more-restricted passes (i.e. BlockPasses could be run in parallel regardless of function for which the block belongs). It also could allow to e.g. run dead block removal only after passes which modify the CFG graph and not after those which only change blocks.
Previously SimplifyCfg pass was unecessarily interleaving many different functions – actual simplification, dead block removal and compaction. This patch splits off dead block removal and compaction into their own passes.
nagisa
force-pushed
the
mir-tiered-passes
branch
from
b1d9e88
to
bd4ddf3
Compare
|
The simplified version looks nice @nagisa! I see though that travis fails with the following: |
|
☔ The latest upstream changes (presumably #31600) made this pull request unmergeable. Please resolve the merge conflicts. |
|
This will be a pain to rebase. I’ll submit a new one later. |
Add Pass manager for MIR A new PR, since rebasing the original one (#31448) properly was a pain. Since then there has been several changes most notable of which: 1. Removed the pretty-printing with `#[rustc_mir(graphviz/pretty)]`, mostly because we now have `--unpretty=mir`, IMHO that’s the direction we should expand this functionality into; 2. Reverted the infercx change done for typeck, because typeck can make an infercx for itself by being a `MirMapPass` r? @nikomatsakis
Previously we would run MIR passes in a very ad-hoc way by calling passses directly everywhere across the compiler. This PR adds a proper pass manager which will run all the passes in some order (decided by the
prioritymethod inPass) right after the MIR is constructed. I believe the pass manager should be general enough to be able to accommodate passes as complex as MIR-based borrowck.The next step here would be to add something like
-Z mir-opt-level=[0..]defaulting to1 + -C opt-leveland afn should_run(&Session)so the passes could decide whether they want to run under a given optimisation level or not.Depends on #31425 landing first.
r? @nikomatsakis