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

incr.comp.: Turn translation-related attributes into a query #48712

Merged
merged 9 commits into from
Mar 8, 2018

Conversation

wesleywiser
Copy link
Member

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 4, 2018
@bors
Copy link
Contributor

bors commented Mar 4, 2018

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 4, 2018
Copy link
Member

@michaelwoerister michaelwoerister left a comment

Choose a reason for hiding this comment

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

Thanks a lot for the very thorough PR, @wesleywiser! This makes a lot of things much nicer, I think, and probably more efficient too.

I added some comments where things need addressing. Just minor things though.

One thing left to do is caching the new query. Doing so is a bit more involved than it should be but it's pretty simple nonetheless:

  1. Mark the query as cacheable like here:
    impl_disk_cacheable_query!(def_symbol_name, |_| true);
  2. Allow for the query to be "refreshed" before writing back out to disk:
    ContainsExternIndicator => contains_extern_indicator,
  3. Actually write query results to disk, like here:
    encode_query_results::<contains_extern_indicator, _>(tcx, enc, qri)?;

} else if trans_fn_attrs.flags.contains(TransFnAttrFlags::UNWIND) {
unwind(llfn, true);
} else if trans_fn_attrs.flags.contains(TransFnAttrFlags::RUSTC_ALLOCATOR_NOUNWIND) {
unwind(llfn, false);
Copy link
Member

Choose a reason for hiding this comment

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

This transformation isn't quite right: We need to always go through all of the ifs instead of chaining them via else. The previous version used else because the body of the for loop would be executed for each attribute individually.

@@ -1156,6 +1158,14 @@ impl<'hir> HashStable<StableHashingContext<'hir>> for hir::TransFnAttrFlags
}
}

impl<'hir> HashStable<StableHashingContext<'hir>> for attr::InlineAttr {
Copy link
Member

Choose a reason for hiding this comment

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

You should be able to use the impl_stable_hash_for! macro, like here:

impl_stable_hash_for!(enum hir::LifetimeName {
Implicit,
Underscore,
Static,
Name(name)
});

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried that but the macro doesn't seem to like the path to that enum. Trying impl_stable_hash_for!(enum attr::InlineAttr { ... }) yields error[E0433]: failed to resolve. Did you mean syntax::attr?

but changing that to impl_stable_hash_for!(enum syntax::attr::InlineAttr { ... }) yields error[E0433]: failed to resolve. Use of undeclared type or module syntax. I'm not sure where to go from here...

@@ -1144,6 +1145,7 @@ impl<'hir> HashStable<StableHashingContext<'hir>> for hir::TransFnAttrs
hcx: &mut StableHashingContext<'hir>,
hasher: &mut StableHasher<W>) {
self.flags.hash_stable(hcx, hasher);
self.inline.hash_stable(hcx, hasher);
Copy link
Member

Choose a reason for hiding this comment

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

We usually de-structure the data types in these implementations:

    fn hash_stable<W: StableHasherResult>(&self,
                                          hcx: &mut StableHashingContext<'hir>,
                                          hasher: &mut StableHasher<W>) {
        let hir::TransFnAttrs {
            flags,
            inline,
        } = *self;

        flags.hash_stable(hcx, hasher);
        inline.hash_stable(hcx, hasher);
    }

This way the code contains an exhaustive list of all fields and one cannot add or remove a field without also updating the impl here. It's a bit more verbose but it is a good way of letting the compiler help keeping things consistent.

@@ -207,7 +207,7 @@ impl<'a, 'tcx> Inliner<'a, 'tcx> {
}

let attrs = tcx.get_attrs(callsite.callee);
Copy link
Member

Choose a reason for hiding this comment

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

We should be able to get rid of this attrs entirely.

Copy link
Member

Choose a reason for hiding this comment

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

Just saw that this is fixed in a later commit :)

Lrc::new(Vec::new()) // Just a dummy

providers.target_features_whitelist = |_tcx, _cnum| {
Rc::new(FxHashSet()) // Just a dummy
Copy link
Member

Choose a reason for hiding this comment

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

This will probably need updating to Lrc too.

@bors
Copy link
Contributor

bors commented Mar 5, 2018

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

@wesleywiser
Copy link
Member Author

wesleywiser commented Mar 6, 2018

@michaelwoerister I resolved all of your feedback except for the issue I mentioned above with the impl_stable_hash_for!(enum) macro.

@michaelwoerister
Copy link
Member

Yes, the macro is sometimes weird like that. With an absolute path (starting with ::syntax) it would probably work.

Thanks for fixing the nits! This looks great!

@bors try (I'd like to see if this affects performance)

@bors r+

@bors
Copy link
Contributor

bors commented Mar 6, 2018

📌 Commit fbcdef5 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 6, 2018
@bors
Copy link
Contributor

bors commented Mar 6, 2018

⌛ Trying commit fbcdef582ec8be6eeef06d90463b226166d07d22 with merge b773dbdc99823e59733116d290342079ba1ca26e...

@bors
Copy link
Contributor

bors commented Mar 6, 2018

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

@bors
Copy link
Contributor

bors commented Mar 6, 2018

⌛ Testing commit fbcdef582ec8be6eeef06d90463b226166d07d22 with merge f24577a22bd6f638589992267b87d23fde912871...

@michaelwoerister
Copy link
Member

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 6, 2018
@michaelwoerister
Copy link
Member

I seems that bors has decided to push this PR to the front of the queue (and kill the one that was almost finished :(). If it goes through, we don't need a separate perf run. Note to myself: don't r+ and try at the same time...

@michaelwoerister
Copy link
Member

@bors r+ (so that bors doesn't suddenly decide to not merge even though all tests have passed)

@bors
Copy link
Contributor

bors commented Mar 6, 2018

📌 Commit fbcdef5 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 6, 2018
@michaelwoerister
Copy link
Member

@Mark-Simulacrum, could you do a perf run please?

@bors
Copy link
Contributor

bors commented Mar 6, 2018

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 6, 2018
@Mark-Simulacrum
Copy link
Member

Perf started for b773dbdc99823e59733116d290342079ba1ca26e.

@michaelwoerister
Copy link
Member

Thanks, @Mark-Simulacrum!

Here's the link: http://perf.rust-lang.org/compare.html?start=1733a61141d125beb45587dd89d54cd4a01cdd5a&end=b773dbdc99823e59733116d290342079ba1ca26e&stat=instructions%3Au

Will this work? Are there build artifacts for the commit? The try-build was f24577a.

@wesleywiser
Copy link
Member Author

Rebased

@Mark-Simulacrum
Copy link
Member

There were two try builds, of which bors seems to think only one completed so I ran perf for that one. The URL you provided looks correct.

@michaelwoerister
Copy link
Member

@bors r+ (after rebase)

@bors
Copy link
Contributor

bors commented Mar 7, 2018

📌 Commit e0f7527 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 7, 2018
@michaelwoerister
Copy link
Member

Thanks, @Mark-Simulacrum, yes the link works now, it's all good :)

The numbers look good too! Pretty much in line with what I expected.

@wesleywiser
Copy link
Member Author

@michaelwoerister Are you concerned about the style-servo and style-servo-opt max regressions?

@michaelwoerister
Copy link
Member

No, that's fine, the clean-incremental benchmark for style-servo is not stable: #48184
There's something in there that causes a varying number of CGUs to be recompiled even if there is no change.

@wesleywiser
Copy link
Member Author

Got it. Thanks!

@alexcrichton alexcrichton merged commit e0f7527 into rust-lang:master Mar 8, 2018
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants