MIR: Bootstrap up to a half-hour longer with --enable-orbit

[alexcrichton]

I just took a look at our list of bots and was surprised that the builder lagging behind was the auto-win-msvc-64-opt-mir builder. Investigating it looks like a MIR bootstrap (--enable-orbit) is taking about a half hour longer than a normal bootstrap. For example compare:

• Normal bootstrap
• MIR bootstrap

In the normal case a bootstrap took 58m and the MIR case took 1h22m. The difference is not always quite as drastic, but historically the normal builders are consistently faster than MIR. The discrepancy also exists on the Linux MIR builders, although it's not quite as large as the Windows machines (~15m slower).

cc @eddyb, @nagisa

[nagisa]

Not surprising, honestly. We still generate worse LLVM-IR (lack of cheap optimising/simplifying transformations) compared to the regular trans, so despite our translation taking a small fraction of the time old trans takes, the LLVM recoups doubly.

[Aatch]

I checked against libsyntax, since it's a nice large crate that LLVM can chew through.

LLVM takes ~50% longer using the MIR trans path compared to the normal one to optimise. Translating to LLVM is actually about the same between them though.

It looks like the main issue is that we're simply generating more IR than before. Some of the LLVM passes have moved up in terms of relative time. One that has shot up quite a lot is SROA. I have a feeling that our handling of function arguments, especially fat pointers, is probably a big part of this.

[sanxiyn]

nickel seems to exhibit an extreme form of this. With nightly-2016-04-29 (which includes #32980), LLVM takes nearly 8x longer.

$ git clone https://github.com/nickel-org/nickel.rs.git
$ cd nickel.rs
$ git checkout 0.8.0
$ cargo build
$ cargo clean -p nickel
$ cargo rustc -- -Z time-passes | grep LLVM
time: 0.740; rss: 144MB LLVM passes
$ cargo clean -p nickel
$ cargo rustc -- -Z orbit -Z time-passes | grep LLVM
time: 5.738; rss: 146MB LLVM passes

[MagaTailor]

Apart from being slower, what's the reason for much larger code size it generates? (e.g. a newly bootstrapped lib directory weighs at 208M vs 180M normally)

[nagisa]

For the same reasons it takes longer to compile. I believe that fixing one will fix another.

Then again, MIR already generates more correct code than the old trans in some corner cases. It should cost some bytes too.

[dotdash]

@sanxiyn A major reason for the difference in nickel in particular is a C-like enum with about 800 variants and a derived PartialEq implementation. That leads to nested matches with about 800 arms each and a basic block for each match arm. So we get about 640k basic blocks in total. SimplifyCfg actually removes most of that going down to about 1.6k basic blocks, but before we enter trans, we break all critical edges and that blows it up to about the initial size again, making LLVM struggle.