[RFC-ish][MIR] Add a pass manager

[nagisa]

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 priority method in Pass) 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 to 1 + -C opt-level and a fn 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

[nikomatsakis]

cc @rust-lang/compiler -- I'd be curious to get others' take here.

[nrc]

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.

[oli-obk]

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.

[oli-obk]

The pass can easily hold information. It's not very useful, but it can do it.

[nagisa]

The point of this invariant is that the pass should not store such information. Primarily because I expect these passes to be pipelined, parallelized, etc in the future. The pass must not rely on getting blocks in any deterministic order. (I realise I also forgot to add a similar invariant for the MirPass)

[nagisa]

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.

I’ve modelled the passes to match the LLVM’s pass structure somewhat closely – namely their ModulePass, FunctionPass and BasicBlockPass. The pass manager itself is pretty barebones currently and I would expect it to grow considerably over time to e.g. share dataflow analysis information between passes.

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).

[nikomatsakis]

On Tue, Feb 09, 2016 at 06:54:29PM -0800, Nick Cameron wrote:

I'm somewhat aghast that mir pass plugins have sneaked into the compiler with no discussion, I think that is a bit premature.

I was also surprised.

[arielb1]

Are there any users for MirBlockPass?

[nagisa]

@arielb1 currently only the test introduced with #31425.

[arielb1]

I mean, what would you use it for?

[nagisa]

@arielb1 I was initially considering it to be a good fit for:

1. A pass which removes the unwind target in case of -Z no-landing-pads;
2. Unnecessary drop removal pass;

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 doInitialization. Lack of such a method is one of the things I had in mind when I was saying that the current implementation might not be flexible enough in its current form.

---

EDIT: to summarize, I, myself, think that in current state, the MirBlockPass is not very useful.

[nagisa]

The 'tcx lifetime might be better on the trait itself.

[arielb1]

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.

[nikomatsakis]

OK so I think these are my overall thoughts:

• Having more flexibility in the kind of pass seems good, and the various choices here some convenient. I like being able to implement the right trait for whatever I want.
• That said, I'm reluctant to add kinds of passes without concrete consumers. Feels maybe like premature abstraction?
• I am wary of integer priorities (as I wrote earlier).
  • I'd rather have a central listing declaring the ordering in which passes will run, personally, so that we can just look at it and know what is going to happen.
  • But then I think you said this was based on whatever LLVM is doing, and maybe it works well for them, I don't know. But it also feels like a case where I'd rather wait to feel the pain before addressing the problem.
  • To accommodate plugin passes, I'd make some "meta passes" at defined points that invoke plugin code.
    • But see https://internals.rust-lang.org/t/mir-compiler-plugins-for-custom-mir-passes/3166/ for more on that topic.

(It may be worth writing an RFC on this, but it also feels like overkill.)

[nagisa]

But then I think you said this was based on whatever LLVM is doing, and maybe it works well for them, I don't know. But it also feels like a case where I'd rather wait to feel the pain before addressing the problem.

Only the pass hierarchy (MirMapPass, MirPass, ...) is based on LLVM. For pass ordering LLVM is using a full-blown dependency graph.

[nagisa]

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), MirPass and MirMapPass stay (these all are useful). I’ll adjust the PR accordingly… someday.

[nikomatsakis]

The simplified version looks nice @nagisa! I see though that travis fails with the following:

---- [run-pass] run-pass-fulldeps/mir-pass.rs stdout ----

error: auxiliary build of "/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs" failed to compile: 
status: exit code: 101
command: x86_64-unknown-linux-gnu/stage2/bin/rustc /home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs -L x86_64-unknown-linux-gnu/test/run-pass-fulldeps/ --target=x86_64-unknown-linux-gnu --crate-type=dylib -L x86_64-unknown-linux-gnu/test/run-pass-fulldeps/mir-pass.stage2-x86_64-unknown-linux-gnu.run-pass.libaux -C prefer-dynamic --out-dir x86_64-unknown-linux-gnu/test/run-pass-fulldeps/mir-pass.stage2-x86_64-unknown-linux-gnu.run-pass.libaux --cfg rtopt -C rpath -O -L x86_64-unknown-linux-gnu/rt
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:21:35: 21:47 error: unresolved import `rustc::mir::transform::MirBlockPass`. There is no `MirBlockPass` in `rustc::mir::transform` [E0432]
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:21 use rustc::mir::transform::{self, MirBlockPass};
                                                                                                            ^~~~~~~~~~~~
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:21:35: 21:47 help: run `rustc --explain E0432` to see a detailed explanation
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:34:5: 36:6 error: method `priority` is not a member of trait `transform::Pass` [E0407]
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:34     fn priority(&self) -> usize {
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:35         1000
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:36     }
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:34:5: 36:6 help: run `rustc --explain E0407` to see a detailed explanation
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:39:6: 39:18 error: `MirBlockPass` is not a trait [E0404]
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:39 impl MirBlockPass for Pass {
                                                                               ^~~~~~~~~~~~
/home/travis/build/rust-lang/rust/src/test/auxiliary/dummy_mir_pass.rs:39:6: 39:18 help: run `rustc --explain E0404` to see a detailed explanation
error: cannot continue compilation due to previous error

------------------------------------------

thread '[run-pass] run-pass-fulldeps/mir-pass.rs' panicked at 'explicit panic', /home/travis/build/rust-lang/rust/src/compiletest/runtest.rs:1529
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    [run-pass] run-pass-fulldeps/mir-pass.rs

[bors]

☔️ The latest upstream changes (presumably #31600) made this pull request unmergeable. Please resolve the merge conflicts.

[nagisa]

This will be a pain to rebase. I’ll submit a new one later.