Skip to content
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

Skip MIR encoding for cargo check #49433

Merged
merged 3 commits into from
Apr 16, 2018
Merged

Conversation

varkor
Copy link
Member

@varkor varkor commented Mar 27, 2018

Resolves #48662.

r? @michaelwoerister

@leonardo-m
Copy link

I think this also works if you use "rustc --emit=metadata" (and you aren't using Cargo).

@varkor
Copy link
Member Author

varkor commented Mar 27, 2018

I think this also works if you use "rustc --emit=metadata" (and you aren't using Cargo).

Yes, this is exactly what cargo check uses behind the scenes :) (I simply mentioned Cargo to align with the original issue.)

@@ -833,6 +833,12 @@ impl<'a, 'b: 'a, 'tcx: 'b> IsolatedEncoder<'a, 'b, 'tcx> {
}
}

fn metadata_output_only(&self) -> bool {
// MIR optimisation can be skipped when we're just interested in the metadata.
self.tcx.sess.opts.output_types.keys().count() == 1 &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a len() impl to OutputTypes in https://github.com/rust-lang/rust/blob/master/src/librustc/session/config.rs and call that instead of the keys(). count().

@nagisa
Copy link
Member

nagisa commented Mar 28, 2018

This solution is debatable. metadata does contain MIR and therefore, it is expected, that with --emit=metadata you get exactly the same object file that would otherwise be included into your final binary (if e.g. emit=link was used).

Basically, it should be possible to reconstruct something resembling a final linked result from component received from --emit=metadata,obj. It perhaps might be worthwhile to simply have a -C flag which disables the optimisations.

@shepmaster
Copy link
Member

r? @nagisa

@shepmaster shepmaster added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 30, 2018
@michaelwoerister
Copy link
Member

michaelwoerister commented Apr 3, 2018

I think the solution is fine. We don't specify that --emit=metadata should be exactly the same as the metadata in an RLIB, just that we have enough metadata to compile downstream crates.

Let's see how much of a difference this even makes:
@bors try

@bors
Copy link
Contributor

bors commented Apr 3, 2018

⌛ Trying commit 308f381 with merge a856992...

bors added a commit that referenced this pull request Apr 3, 2018
Skip MIR optimisation for cargo check

Resolves #48662.

r? @michaelwoerister
@michaelwoerister
Copy link
Member

After chatting a bit on IRC, @nagisa and I came to the conclusion that it would be better (i.e. more future-proof) to use -Zmir-opt-level for reducing the amount of optimization we do. @nagisa, would you be able to help @varkor with reviewing the optimization passes? I'm not quite sure which of those are actually needed for correctness.

@bors
Copy link
Contributor

bors commented Apr 3, 2018

💥 Test timed out

@michaelwoerister
Copy link
Member

@bors try

@michaelwoerister
Copy link
Member

Maybe we should discuss this in @rust-lang/compiler meeting. The PR, as implemented here does not really pose a regression to what one can do with --emit=metadata RLIBs (as @eddyb pointed out on IRC): One can already not compile a regular crate with a metadata-only RLIB dependency. Not computing and storing the MIR does seem like the most efficient approach.

@michaelwoerister
Copy link
Member

@Mark-Simulacrum, something has gone wrong with the try-build. Could you restart it? I want to get some perf numbers in order to find out if the speedups are even worth the fuss :)

@@ -246,6 +246,10 @@ impl OutputTypes {
self.0.values()
}

pub fn len(&self) -> usize {
self.0.keys().count()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't BTreeMap have a len method?

@nagisa
Copy link
Member

nagisa commented Apr 3, 2018

So a mir-opt-level based solution would end up looking like this for almost every MIR pass.

A number of passes here are all a good target for having their mir-opt-level bumped.

AFAIR currently mir-opt-level = opt-level + 1 specifically to allow checking against mir-opt-level > 0 to almost always run the pass, and to allow specifying -Zmir-opt-level=0 to disable most of the passes that matter.

It might make sense to stabilise this option to some degree and also review which passes are run at what levels.

@eddyb
Copy link
Member

eddyb commented Apr 4, 2018

I don't understand why we need to touch anything about optimizations, instead of the current status of the PR which skips encoding? I expect serializing MIR to potentially be costlier than doing most of the enabled-by-default optimizations.

@nagisa
Copy link
Member

nagisa commented Apr 4, 2018

Oh, that is a fair point, and I had completely missed that, due to how trivial the PR looked and how misleading the title was.

I guess this approach works for me then provided we figure out what exactly would make sure that we still end up querying the "analysed" MIR for everything, so that MIR borrowck and friends are still executed.

cc @nikomatsakis what ensures that "analysed" MIR is queried if "optimised" MIR is not?

@varkor varkor changed the title Skip MIR optimisation for cargo check Skip MIR encoding for cargo check Apr 4, 2018
@ishitatsuyuki
Copy link
Contributor

ishitatsuyuki commented Apr 7, 2018

With the current commits, is MIR emitting suppressed, or is it still emitted unoptimised? It looks like you have changed the title, but I'm not sure if the patch reflects it.

Edit: looks like disabling MIR inlining also suppress MIR encoding.

Also, I'd prefer having this as a flag, similar to what @nagisa said. I have #44587 in mind, and we should not diverge rmeta from what is embedded inside the rlib.

@@ -833,6 +833,12 @@ impl<'a, 'b: 'a, 'tcx: 'b> IsolatedEncoder<'a, 'b, 'tcx> {
}
}

fn metadata_output_only(&self) -> bool {
// MIR optimisation can be skipped when we're just interested in the metadata.
self.tcx.sess.opts.output_types.len() == 1 &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cargo also includes dep-info as output; we probably need to check if we have anything any output that requires codegen.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! This method could be implemented as

fn metadata_output_only(&self) -> bool {
    // MIR optimisation can be skipped when we're just interested in the metadata.
    !self.tcx.sess.opts.output_types.should_trans()
}

@ishitatsuyuki
Copy link
Contributor

How much does this speed up cargo check? I think bors retry will restart the try build.

@michaelwoerister
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Apr 10, 2018

⌛ Trying commit 5576ce8 with merge f2c12f4...

bors added a commit that referenced this pull request Apr 10, 2018
@michaelwoerister
Copy link
Member

@ishitatsuyuki Let's take a look.

@rust-lang rust-lang deleted a comment from TimNN Apr 10, 2018
@bors
Copy link
Contributor

bors commented Apr 10, 2018

☀️ Test successful - status-travis
State: approved= try=True

@ishitatsuyuki
Copy link
Contributor

@Mark-Simulacrum Can you please start a perf run?

@Mark-Simulacrum
Copy link
Member

Perf started.

@ishitatsuyuki
Copy link
Contributor

Up to 10% faster on check, others are noise.

https://perf.rust-lang.org/compare.html?start=2018-04-07&end=f2c12f4397efb47adcaa152b1e63e1051b209a7b&stat=instructions%3Au

@ishitatsuyuki
Copy link
Contributor

I think we can merge this. Any concerns? @nagisa @michaelwoerister

@michaelwoerister
Copy link
Member

I'm interpreting @nagisa's comment as him being OK with it.

@bors r+

Thanks again, @varkor!

@bors
Copy link
Contributor

bors commented Apr 16, 2018

📌 Commit 5576ce8 has been approved by michaelwoerister

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 16, 2018
@bors
Copy link
Contributor

bors commented Apr 16, 2018

⌛ Testing commit 5576ce8 with merge d6a2dd9...

bors added a commit that referenced this pull request Apr 16, 2018
@bors
Copy link
Contributor

bors commented Apr 16, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing d6a2dd9 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants