-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Switch to MIR-based translation by default. #34096
Conversation
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
@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 I hope time this PR will need to go through the queue will be enough for all relevant parties to see this. |
📌 Commit ce179ea has been approved by |
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 cc @rust-lang/compiler |
hold hold hold canceling pending a crater run |
… and niko’s seal of approval, of course, which implies |
Whoa, how about #33828? |
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. |
@alexbool Those numbers predate non-zeroing drops. I can take a look, I suppose, maybe it has a completely different reason. |
@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) |
Thanks, sounds convincing |
The Travis failure is strange, although likely legitimate:
@alexcrichton Is it possible |
@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. |
@eddyb oh we probably don't pass @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... |
Let's discuss a bit here perhaps: http://internals.rust-lang.org/t/enabling-mir-by-default/3555 ? |
@NastyRigger I have one data point for (compiler) memory usage: |
[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.
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? |
@eddyb @brson I remember comparing binary sizes of During the latter test Edit: Cargo binary is made 8% smaller. |
@brson Actually, I mentioned libsyntax using less memory to compile, here's the timings/RSS:
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). |
Will old trans be tested by Buildbot after this PR is merged? |
@sanxiyn Good question. We could technically flip the MIR bots to be "anti-MIR". cc @alexcrichton |
@alexcrichton As explained in the PR description, both |
Clearly I also need a PR to read more things, thanks @eddyb! |
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 |
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 think that last part may be a bit optimistic, but then... here's hoping. =) |
@bors r+ |
📌 Commit d2f2df1 has been approved by |
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
💔 Test failed - auto-mac-32-opt |
@bors r=nikomatsakis |
📌 Commit b583711 has been approved by |
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
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