Switch to MIR-based translation by default. #34096

Merged
merged 7 commits into from Aug 2, 2016

Conversation

Projects
None yet
@eddyb
Member

eddyb commented Jun 5, 2016

This patch makes -Z orbit default to "on", which means that by default, functions will be translated from Rust to LLVM IR through the upcoming MIR backend, instead of the antiquated AST backend.

This switch is made possible by the recently merged #33622, #33905 and smaller fixes.

If you experience any issues, please file a report for each of them. You can switch to the old backend to work around problems by either setting RUSTFLAGS="-Zorbit=off" or by annotating specific functions with #[rustc_no_mir] (which requires #![feature(rustc_attrs)] at the crate-level).

I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.

cc @rust-lang/compiler

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jun 5, 2016

Collaborator

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Jun 5, 2016

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Jun 5, 2016

Contributor

@bors r+

I feel like approving this PR for nightly makes a lot of sense. We’ve been testing and improving MIR for a while now and making it default on nightly will get MIR to many more hands than we had before so far.

One concern I have that as the PR is now its pretty easy to forget to flip the true to false before the branch to beta if we figure out that we are not ready to enable this yet. On the other hand, reversing enablement is as easy of an one-line-change, so @eddyb convinced me that it will be fine.

I hope time this PR will need to go through the queue will be enough for all relevant parties to see this.

Contributor

nagisa commented Jun 5, 2016

@bors r+

I feel like approving this PR for nightly makes a lot of sense. We’ve been testing and improving MIR for a while now and making it default on nightly will get MIR to many more hands than we had before so far.

One concern I have that as the PR is now its pretty easy to forget to flip the true to false before the branch to beta if we figure out that we are not ready to enable this yet. On the other hand, reversing enablement is as easy of an one-line-change, so @eddyb convinced me that it will be fine.

I hope time this PR will need to go through the queue will be enough for all relevant parties to see this.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jun 5, 2016

Contributor

📌 Commit ce179ea has been approved by nagisa

Contributor

bors commented Jun 5, 2016

📌 Commit ce179ea has been approved by nagisa

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Jun 5, 2016

Contributor

Sure. We have to flip that switch someday, and it's not like we will discover any new bugs with the switch set to off.

On the other hand, I would prefer a crater run with LLVM assertions enabled. I would prefer that to a dump of confusing ICE reports.

There are only 3 PRs left on the queue, and our build times improved since the opt-mir builds are no longer holding things up - this PR may go today UTC, and I am not sure @nikomatsakis is online.

cc @rust-lang/compiler

Contributor

arielb1 commented Jun 5, 2016

Sure. We have to flip that switch someday, and it's not like we will discover any new bugs with the switch set to off.

On the other hand, I would prefer a crater run with LLVM assertions enabled. I would prefer that to a dump of confusing ICE reports.

There are only 3 PRs left on the queue, and our build times improved since the opt-mir builds are no longer holding things up - this PR may go today UTC, and I am not sure @nikomatsakis is online.

cc @rust-lang/compiler

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Jun 5, 2016

Contributor

hold hold hold
@bors r-

canceling pending a crater run

Contributor

arielb1 commented Jun 5, 2016

hold hold hold
@bors r-

canceling pending a crater run

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Jun 5, 2016

Contributor

… and niko’s seal of approval, of course, which implies

r? @nikomatsakis

Contributor

nagisa commented Jun 5, 2016

… and niko’s seal of approval, of course, which implies

r? @nikomatsakis

@alexbool

This comment has been minimized.

Show comment
Hide comment
@alexbool

alexbool Jun 5, 2016

Contributor

Whoa, how about #33828?

Contributor

alexbool commented Jun 5, 2016

Whoa, how about #33828?

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Jun 5, 2016

Contributor

I personally do not see performance regressions as a blocker to enable MIR in nightly by default, because otherwise we will never end up enabling it at all. Rather, enabling MIR by default on nightly would serve to help collect more reports on issues with MIR (both performance and correctness) and speed up fixing said issues. Perhaps all within the same cycle.

Contributor

nagisa commented Jun 5, 2016

I personally do not see performance regressions as a blocker to enable MIR in nightly by default, because otherwise we will never end up enabling it at all. Rather, enabling MIR by default on nightly would serve to help collect more reports on issues with MIR (both performance and correctness) and speed up fixing said issues. Perhaps all within the same cycle.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 5, 2016

Member

@alexbool Those numbers predate non-zeroing drops. I can take a look, I suppose, maybe it has a completely different reason.

Member

eddyb commented Jun 5, 2016

@alexbool Those numbers predate non-zeroing drops. I can take a look, I suppose, maybe it has a completely different reason.

@alexbool

This comment has been minimized.

Show comment
Hide comment
@alexbool

alexbool Jun 5, 2016

Contributor

@eddyb How is that related to non-zeroing drops? If I get it right, MIR and old code both use the same zeroing drops in that benchmark, so the competion is fair. (Please tell me if I am wrong)

Contributor

alexbool commented Jun 5, 2016

@eddyb How is that related to non-zeroing drops? If I get it right, MIR and old code both use the same zeroing drops in that benchmark, so the competion is fair. (Please tell me if I am wrong)

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 5, 2016

Member

@alexbool Old trans can actually handle some static drop/unconditional move cases better than MIR trans did before #33622 - MIR trans used to generate a ton of memsets with the "uninitialized" and "dropped" byte patterns instead.

Member

eddyb commented Jun 5, 2016

@alexbool Old trans can actually handle some static drop/unconditional move cases better than MIR trans did before #33622 - MIR trans used to generate a ton of memsets with the "uninitialized" and "dropped" byte patterns instead.

@alexbool

This comment has been minimized.

Show comment
Hide comment
@alexbool

alexbool Jun 5, 2016

Contributor

Thanks, sounds convincing

Contributor

alexbool commented Jun 5, 2016

Thanks, sounds convincing

@eddyb eddyb referenced this pull request Jun 5, 2016

Closed

MIR 4x slower #33828

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 5, 2016

Member

The Travis failure is strange, although likely legitimate:

run doc-book-lang-items [x86_64-unknown-linux-gnu]

running 1 test
test _0 ... FAILED

failures:

---- _0 stdout ----
    <anon>:36:9: 36:13 warning: unused variable: `argc`, #[warn(unused_variables)] on by default
<anon>:36 fn main(argc: isize, argv: *const *const u8) -> isize {
                  ^~~~
<anon>:36:22: 36:26 warning: unused variable: `argv`, #[warn(unused_variables)] on by default
<anon>:36 fn main(argc: isize, argv: *const *const u8) -> isize {
                               ^~~~
<anon>:37:9: 37:10 warning: unused variable: `x`, #[warn(unused_variables)] on by default
<anon>:37     let x = box 1;
                  ^
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/rustdoctest.goiITNucvd13/rust_out.0.o" "-o" "/tmp/rustdoctest.goiITNucvd13/rust_out" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-fe3cdf61.rlib" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-fe3cdf61.rlib" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt"
note: /tmp/rustdoctest.goiITNucvd13/rust_out.0.o: In function `rust_out::main::hec68da2489a63b6a':
rust_out.0.rs:(.text._ZN8rust_out4main17hec68da2489a63b6aE+0x6a): undefined reference to `_Unwind_Resume'
collect2: error: ld returned 1 exit status

error: aborting due to previous error
thread '_0' panicked at 'Box<Any>', src/libsyntax/errors/mod.rs:622
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '_0' panicked at 'couldn't compile the test', src/librustdoc/test.rs:281


failures:
    _0

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

/build/mk/tests.mk:865: recipe for target 'tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-doc-book-lang-items.ok' failed
make: *** [tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-doc-book-lang-items.ok] Error 101

@alexcrichton Is it possible --enable-orbit doesn't work for everything we run, in this case rustdoc?

Member

eddyb commented Jun 5, 2016

The Travis failure is strange, although likely legitimate:

run doc-book-lang-items [x86_64-unknown-linux-gnu]

running 1 test
test _0 ... FAILED

failures:

---- _0 stdout ----
    <anon>:36:9: 36:13 warning: unused variable: `argc`, #[warn(unused_variables)] on by default
<anon>:36 fn main(argc: isize, argv: *const *const u8) -> isize {
                  ^~~~
<anon>:36:22: 36:26 warning: unused variable: `argv`, #[warn(unused_variables)] on by default
<anon>:36 fn main(argc: isize, argv: *const *const u8) -> isize {
                               ^~~~
<anon>:37:9: 37:10 warning: unused variable: `x`, #[warn(unused_variables)] on by default
<anon>:37     let x = box 1;
                  ^
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/rustdoctest.goiITNucvd13/rust_out.0.o" "-o" "/tmp/rustdoctest.goiITNucvd13/rust_out" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-fe3cdf61.rlib" "/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-fe3cdf61.rlib" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt"
note: /tmp/rustdoctest.goiITNucvd13/rust_out.0.o: In function `rust_out::main::hec68da2489a63b6a':
rust_out.0.rs:(.text._ZN8rust_out4main17hec68da2489a63b6aE+0x6a): undefined reference to `_Unwind_Resume'
collect2: error: ld returned 1 exit status

error: aborting due to previous error
thread '_0' panicked at 'Box<Any>', src/libsyntax/errors/mod.rs:622
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '_0' panicked at 'couldn't compile the test', src/librustdoc/test.rs:281


failures:
    _0

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

/build/mk/tests.mk:865: recipe for target 'tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-doc-book-lang-items.ok' failed
make: *** [tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-doc-book-lang-items.ok] Error 101

@alexcrichton Is it possible --enable-orbit doesn't work for everything we run, in this case rustdoc?

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 5, 2016

Member

@alexcrichton The example seems fundamentally broken and only happens to work with old trans because no landing pads get generated for that exact code. Although the fix appears to be simple so I'll just include it here.

Member

eddyb commented Jun 5, 2016

@alexcrichton The example seems fundamentally broken and only happens to work with old trans because no landing pads get generated for that exact code. Although the fix appears to be simple so I'll just include it here.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 6, 2016

Member

@eddyb oh we probably don't pass RUSTFLAGS to the rustdoc unit tests (or rustdoc also just doesn't accept -Z), explaining at least why we didn't see it before.

@eddyb also yeah I'm fine with mangling that test or otherwise just ignoring it, it seems like a difficult thing to test anyway. Having it as part of rustdoc also probably isn't helping us much...

Member

alexcrichton commented Jun 6, 2016

@eddyb oh we probably don't pass RUSTFLAGS to the rustdoc unit tests (or rustdoc also just doesn't accept -Z), explaining at least why we didn't see it before.

@eddyb also yeah I'm fine with mangling that test or otherwise just ignoring it, it seems like a difficult thing to test anyway. Having it as part of rustdoc also probably isn't helping us much...

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
Contributor

nikomatsakis commented Jun 6, 2016

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 6, 2016

Member

@NastyRigger I have one data point for (compiler) memory usage: 625MB -> 604MB from old trans to MIR trans, on stage1 libsyntax, just after LLVM passes.

Member

eddyb commented Jun 6, 2016

@NastyRigger I have one data point for (compiler) memory usage: 625MB -> 604MB from old trans to MIR trans, on stage1 libsyntax, just after LLVM passes.

bors added a commit that referenced this pull request Jun 7, 2016

Auto merge of #34128 - eddyb:mir-trans-fixes, r=luqmana
[MIR] Fix MIR trans edge cases that showed up on crater.

These fixes cover all of the [regressions found by crater](https://gist.github.com/nikomatsakis/88ce89ed06ef7f7f19bfd1e221d7f7ec) (for #34096).

Two of them were `Pair` edge cases (ZSTs and constants) causing LLVM assertions, the other one was  causing stack overflows in debug scripts compiled in debug mode, due to the `fn_ret_cast` `alloca` ending up in a loop.
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 7, 2016

Contributor

I personally do not see performance regressions as a blocker to enable MIR in nightly by default, because otherwise we will never end up enabling it at al

Once MIR is on the likelyhood of us turning it back on seems very low, so I have to disagree with this. We must hold the line on performance - we have already regressed compile time performance badly this year. Do we have evidence that compile time, run time and code size are on par with oldtrans?

Contributor

brson commented Jun 7, 2016

I personally do not see performance regressions as a blocker to enable MIR in nightly by default, because otherwise we will never end up enabling it at al

Once MIR is on the likelyhood of us turning it back on seems very low, so I have to disagree with this. We must hold the line on performance - we have already regressed compile time performance badly this year. Do we have evidence that compile time, run time and code size are on par with oldtrans?

@MagaTailor

This comment has been minimized.

Show comment
Hide comment
@MagaTailor

MagaTailor Jun 7, 2016

@eddyb @brson I remember comparing binary sizes of parity and rust's lib directory a few weeks ago. I've just finished repeating the tests, and to my utter surprise, instead of 10% larger, MIR produced a 5% smaller parity binary, whereas the lib directory ended up 1.7% smaller. (32-bit ARM data)

During the latter test /usr/bin/time -v make -j2 showed maximum resident memory size of 543124 kB vs 391828 kB (probably librustc), in favour of MIR again. I wasn't able to benchmark compilation times but other than that, MIR seems to have improved immensely!

Edit: Cargo binary is made 8% smaller.

MagaTailor commented Jun 7, 2016

@eddyb @brson I remember comparing binary sizes of parity and rust's lib directory a few weeks ago. I've just finished repeating the tests, and to my utter surprise, instead of 10% larger, MIR produced a 5% smaller parity binary, whereas the lib directory ended up 1.7% smaller. (32-bit ARM data)

During the latter test /usr/bin/time -v make -j2 showed maximum resident memory size of 543124 kB vs 391828 kB (probably librustc), in favour of MIR again. I wasn't able to benchmark compilation times but other than that, MIR seems to have improved immensely!

Edit: Cargo binary is made 8% smaller.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 7, 2016

Member

@brson Actually, I mentioned libsyntax using less memory to compile, here's the timings/RSS:
Old trans:

time: 11.669; rss: 734MB        translation
  time: 4.534; rss: 621MB       llvm function passes [0]
  time: 94.234; rss: 623MB      llvm module passes [0]
  time: 26.816; rss: 625MB      codegen passes [0]
  time: 0.003; rss: 625MB       codegen passes [0]
time: 126.276; rss: 625MB       LLVM passes

-Z orbit:

time: 12.615; rss: 727MB        translation
  time: 4.449; rss: 634MB       llvm function passes [0]
  time: 69.080; rss: 634MB      llvm module passes [0]
  time: 25.928; rss: 636MB      codegen passes [0]
  time: 0.002; rss: 604MB       codegen passes [0]
time: 100.045; rss: 604MB       LLVM passes

LLVM spends 26 seconds less optimizing the result of trans and uses 20 MBs less of RAM, at the cost of one extra second spent in MIR translation (which could be some missing caching on type/trait stuff).

Member

eddyb commented Jun 7, 2016

@brson Actually, I mentioned libsyntax using less memory to compile, here's the timings/RSS:
Old trans:

time: 11.669; rss: 734MB        translation
  time: 4.534; rss: 621MB       llvm function passes [0]
  time: 94.234; rss: 623MB      llvm module passes [0]
  time: 26.816; rss: 625MB      codegen passes [0]
  time: 0.003; rss: 625MB       codegen passes [0]
time: 126.276; rss: 625MB       LLVM passes

-Z orbit:

time: 12.615; rss: 727MB        translation
  time: 4.449; rss: 634MB       llvm function passes [0]
  time: 69.080; rss: 634MB      llvm module passes [0]
  time: 25.928; rss: 636MB      codegen passes [0]
  time: 0.002; rss: 604MB       codegen passes [0]
time: 100.045; rss: 604MB       LLVM passes

LLVM spends 26 seconds less optimizing the result of trans and uses 20 MBs less of RAM, at the cost of one extra second spent in MIR translation (which could be some missing caching on type/trait stuff).

@sanxiyn

This comment has been minimized.

Show comment
Hide comment
@sanxiyn

sanxiyn Jun 8, 2016

Member

Will old trans be tested by Buildbot after this PR is merged?

Member

sanxiyn commented Jun 8, 2016

Will old trans be tested by Buildbot after this PR is merged?

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 8, 2016

Member

@sanxiyn Good question. We could technically flip the MIR bots to be "anti-MIR". cc @alexcrichton

Member

eddyb commented Jun 8, 2016

@sanxiyn Good question. We could technically flip the MIR bots to be "anti-MIR". cc @alexcrichton

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 8, 2016

Member

Yeah that sounds like a good strategy, after this lands we'll update those two bots to pass --disable-orbit instead of passing --enable-orbit

Member

alexcrichton commented Jun 8, 2016

Yeah that sounds like a good strategy, after this lands we'll update those two bots to pass --disable-orbit instead of passing --enable-orbit

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Jun 8, 2016

Member

Another vote for relatively strict constraints on turning this on based on compile time and runtime performance. I'm not sure exactly what those criteria should look like, but we should agree a 1.x regression for compile time performance, say, and not land before we achieve that.

Member

nrc commented Jun 8, 2016

Another vote for relatively strict constraints on turning this on based on compile time and runtime performance. I'm not sure exactly what those criteria should look like, but we should agree a 1.x regression for compile time performance, say, and not land before we achieve that.

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Jun 8, 2016

Contributor

@nrc

The problem with guaranteeing no performance regressions is that LLVM's optimizer is very unpredictable, and any small change in code generation may make it no longer detect some loop as a memcpy and cause an 200% degradation in the relevant microbenchmark.

This, of course, applies both ways - there are surely cases where a memcpy is detected with MIR trans and not with old trans.

However, from what we manage to understand, on typical code the performance differences are in order of a few percents, and often in favor of MIR. If MIR was already enabled, we would not transition to old trans because of these levels of differences. After MIR is enabled by default, we will be able to get better feedback on its edge cases, and I think that MIR optimizations will be worth a few more percents in compilation time.

Contributor

arielb1 commented Jun 8, 2016

@nrc

The problem with guaranteeing no performance regressions is that LLVM's optimizer is very unpredictable, and any small change in code generation may make it no longer detect some loop as a memcpy and cause an 200% degradation in the relevant microbenchmark.

This, of course, applies both ways - there are surely cases where a memcpy is detected with MIR trans and not with old trans.

However, from what we manage to understand, on typical code the performance differences are in order of a few percents, and often in favor of MIR. If MIR was already enabled, we would not transition to old trans because of these levels of differences. After MIR is enabled by default, we will be able to get better feedback on its edge cases, and I think that MIR optimizations will be worth a few more percents in compilation time.

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Jun 8, 2016

Contributor

However, better tracking of compiler performance would surely be a nice thing. I would really like a (commit, benchmark, pass, time) database somewhere, preferably with at least one commit per day.

Contributor

arielb1 commented Jun 8, 2016

However, better tracking of compiler performance would surely be a nice thing. I would really like a (commit, benchmark, pass, time) database somewhere, preferably with at least one commit per day.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 10, 2016

Contributor

Thanks for the updates @petevine @eddyb. Looking real good.

Contributor

brson commented Jun 10, 2016

Thanks for the updates @petevine @eddyb. Looking real good.

src/doc/book/lang-items.md
@@ -19,6 +19,8 @@ sugar for dynamic allocations via `malloc` and `free`:
#![feature(lang_items, box_syntax, start, libc)]
#![no_std]
+# #![feature(panic_unwind)]

This comment has been minimized.

@DemiMarie

DemiMarie Jun 24, 2016

Contributor

Are the leading #s typos?

@DemiMarie

DemiMarie Jun 24, 2016

Contributor

Are the leading #s typos?

This comment has been minimized.

@solson

solson Jun 24, 2016

Member

No, that's rustdoc syntax which hides these lines from the rendered output.

It's explained a few paragraphs down at https://doc.rust-lang.org/book/documentation.html#documentation-as-tests.

@solson

solson Jun 24, 2016

Member

No, that's rustdoc syntax which hides these lines from the rendered output.

It's explained a few paragraphs down at https://doc.rust-lang.org/book/documentation.html#documentation-as-tests.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 26, 2016

Member

Given servo/servo#11872, Servo passes tests again with -Zorbit, if anyone wants to give that a try.
I've played around with the dromaeo test suite, but the variance on that is crazy, bigger difference between consecutive test runs with the same build than between two significantly different builds.
MIR seemed to have lower times across the board, so maybe that means something? But maybe not.

Member

eddyb commented Jun 26, 2016

Given servo/servo#11872, Servo passes tests again with -Zorbit, if anyone wants to give that a try.
I've played around with the dromaeo test suite, but the variance on that is crazy, bigger difference between consecutive test runs with the same build than between two significantly different builds.
MIR seemed to have lower times across the board, so maybe that means something? But maybe not.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 27, 2016

Member

@eddyb nice!

Also as an update to this @nikomatsakis has created a milestone to track MIR blockers, although there are only two issues on it so far.

Ah and one other minor technical point about this PR, @eddyb could you make sure there's an option to disable MIR for the near future? Right now it looks like there's no way to use old trans, right?

Member

alexcrichton commented Jun 27, 2016

@eddyb nice!

Also as an update to this @nikomatsakis has created a milestone to track MIR blockers, although there are only two issues on it so far.

Ah and one other minor technical point about this PR, @eddyb could you make sure there's an option to disable MIR for the near future? Right now it looks like there's no way to use old trans, right?

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 27, 2016

Member

@alexcrichton As explained in the PR description, both RUSTFLAGS="-Zorbit=off" and the #[rustc_no_mir] function attribute will work to switch to old trans for the whole compilation or just a function.

Member

eddyb commented Jun 27, 2016

@alexcrichton As explained in the PR description, both RUSTFLAGS="-Zorbit=off" and the #[rustc_no_mir] function attribute will work to switch to old trans for the whole compilation or just a function.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 27, 2016

Member

Clearly I also need a PR to read more things, thanks @eddyb!

Member

alexcrichton commented Jun 27, 2016

Clearly I also need a PR to read more things, thanks @eddyb!

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 19, 2016

Member

I'm going to close this just to help clear out the queue, but the progress for this is tracked on https://github.com/rust-lang/rust/milestone/29

Member

alexcrichton commented Jul 19, 2016

I'm going to close this just to help clear out the queue, but the progress for this is tracked on https://github.com/rust-lang/rust/milestone/29

@eddyb eddyb reopened this Aug 1, 2016

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 1, 2016

Contributor

After some discussion on IRC, we decided to go forward with this -- MIR is looking good, with no known functional regressions, and we're ready to see how it fares with the broader, nightly audience. =) As @eddyb wrote, albeit for a different nightly:

I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.

I think that last part may be a bit optimistic, but then... here's hoping. =)

Contributor

nikomatsakis commented Aug 1, 2016

After some discussion on IRC, we decided to go forward with this -- MIR is looking good, with no known functional regressions, and we're ready to see how it fares with the broader, nightly audience. =) As @eddyb wrote, albeit for a different nightly:

I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.

I think that last part may be a bit optimistic, but then... here's hoping. =)

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 1, 2016

Contributor

@bors r+

Contributor

nikomatsakis commented Aug 1, 2016

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 1, 2016

Contributor

📌 Commit d2f2df1 has been approved by nikomatsakis

Contributor

bors commented Aug 1, 2016

📌 Commit d2f2df1 has been approved by nikomatsakis

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 1, 2016

Contributor

⌛️ Testing commit d2f2df1 with merge 5713448...

Contributor

bors commented Aug 1, 2016

⌛️ Testing commit d2f2df1 with merge 5713448...

bors added a commit that referenced this pull request Aug 1, 2016

Auto merge of #34096 - eddyb:launch, r=nikomatsakis
Switch to MIR-based translation by default.

This patch makes `-Z orbit` default to "on", which means that by default, functions will be translated from Rust to LLVM IR through the upcoming MIR backend, instead of the antiquated AST backend.

This switch is made possible by the recently merged #33622, #33905 and smaller fixes.

If you experience any issues, please file a report for each of them. You can switch to the old backend to work around problems by either setting `RUSTFLAGS="-Zorbit=off"` or by annotating specific functions with `#[rustc_no_mir]` (which requires `#![feature(rustc_attrs)]` at the crate-level).

I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.

cc @rust-lang/compiler
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 2, 2016

Contributor

💔 Test failed - auto-mac-32-opt

Contributor

bors commented Aug 2, 2016

💔 Test failed - auto-mac-32-opt

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Aug 2, 2016

Member

@bors r=nikomatsakis

Member

eddyb commented Aug 2, 2016

@bors r=nikomatsakis

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 2, 2016

Contributor

📌 Commit b583711 has been approved by nikomatsakis

Contributor

bors commented Aug 2, 2016

📌 Commit b583711 has been approved by nikomatsakis

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 2, 2016

Contributor

⌛️ Testing commit b583711 with merge 34d14e7...

Contributor

bors commented Aug 2, 2016

⌛️ Testing commit b583711 with merge 34d14e7...

bors added a commit that referenced this pull request Aug 2, 2016

Auto merge of #34096 - eddyb:launch, r=nikomatsakis
Switch to MIR-based translation by default.

This patch makes `-Z orbit` default to "on", which means that by default, functions will be translated from Rust to LLVM IR through the upcoming MIR backend, instead of the antiquated AST backend.

This switch is made possible by the recently merged #33622, #33905 and smaller fixes.

If you experience any issues, please file a report for each of them. You can switch to the old backend to work around problems by either setting `RUSTFLAGS="-Zorbit=off"` or by annotating specific functions with `#[rustc_no_mir]` (which requires `#![feature(rustc_attrs)]` at the crate-level).

I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.

cc @rust-lang/compiler

@bors bors merged commit b583711 into rust-lang:master Aug 2, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@eddyb eddyb deleted the eddyb:launch branch Aug 2, 2016

@ernestrc ernestrc referenced this pull request in racer-rust/racer Aug 2, 2016

Closed

MIR #586

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment