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

Compute default query providers at compile-time #87040

Closed
wants to merge 2 commits into from

Conversation

Aaron1011
Copy link
Member

All of the provide functions are made const, allowing
us to compute the default local and extern query providers
entirely at compile-time.

In addition to moving runtime work to compile-time, this will
allow our internal documentation to show all query implementations,
once #87038 is implemented.

All of the `provide` functions are made `const`, allowing
us to compute the default local and extern query providers
entirely at compile-time.

In addition to moving runtime work to compile-time, this will
allow our internal documentation to show all query implementations,
once rust-lang#87038 is implemented.
@rust-highfive
Copy link
Collaborator

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 10, 2021
@Aaron1011
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 10, 2021
@bors
Copy link
Contributor

bors commented Jul 10, 2021

⌛ Trying commit 366f8f3 with merge a50316edc0300b2760fd4fcb6df11c2851875464...

@@ -737,35 +736,35 @@ pub fn prepare_outputs(
Ok(outputs)
}

pub static DEFAULT_QUERY_PROVIDERS: SyncLazy<Providers> = SyncLazy::new(|| {
let providers = &mut Providers::default();
pub const DEFAULT_QUERY_PROVIDERS: Providers = {
Copy link
Member

Choose a reason for hiding this comment

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

This isn't the same semantics as before, it will make a copy of the Providers struct everywhere it's used (which defeats the whole point of having this in rustc proper, originally in #73566 I just use a thread_local in rustdoc and @eddyb asked me not to for performance reasons).

Suggested change
pub const DEFAULT_QUERY_PROVIDERS: Providers = {
pub static DEFAULT_QUERY_PROVIDERS: Providers = {

Copy link
Member Author

Choose a reason for hiding this comment

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

We already copy DEFAULT_QUERY_PROVIDERS in both places where it's used, so making this a static will just result in an unnecessary static allocation in the final library.

Copy link
Member

Choose a reason for hiding this comment

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

It's not copied in rustdoc:

> rg DEFAULT_QUERY_PROVIDERS src/librustdoc/
src/librustdoc/core.rs
295:                (rustc_interface::DEFAULT_QUERY_PROVIDERS.typeck)(tcx, def_id)

Copy link
Member

Choose a reason for hiding this comment

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

Anyway, I'm not completely opposed to changing it, but I don't think it belongs here. AIUI the point of this is to compute the providers at compiletime, which you can do without changing these to consts.

providers
};

pub const DEFAULT_EXTERN_QUERY_PROVIDERS: Providers = {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
pub const DEFAULT_EXTERN_QUERY_PROVIDERS: Providers = {
pub static DEFAULT_EXTERN_QUERY_PROVIDERS: Providers = {

@jyn514 jyn514 added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 10, 2021
@petrochenkov
Copy link
Contributor

I know that something like this was unsuccessfully tried previously - #74283.
r? @cjgillot @eddyb

@jyn514
Copy link
Member

jyn514 commented Jul 10, 2021

Oh yay, that was the PR I was looking for: #74347. Yes, changing static to const defeats the whole point of that and at that point I'm not sure what advantage the const has over a const fn.

@bors
Copy link
Contributor

bors commented Jul 10, 2021

☀️ Try build successful - checks-actions
Build commit: a50316edc0300b2760fd4fcb6df11c2851875464 (a50316edc0300b2760fd4fcb6df11c2851875464)

@rust-timer
Copy link
Collaborator

Queued a50316edc0300b2760fd4fcb6df11c2851875464 with parent a31431f, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (a50316edc0300b2760fd4fcb6df11c2851875464): comparison url.

Summary: This change led to significant regressions 😿 in compiler performance.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jul 11, 2021
@Aaron1011
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 11, 2021
@bors
Copy link
Contributor

bors commented Jul 11, 2021

⌛ Trying commit aaeca08 with merge 24c4eabf24250ef1b13b23eb38ad979c56316abb...

@bors
Copy link
Contributor

bors commented Jul 11, 2021

☀️ Try build successful - checks-actions
Build commit: 24c4eabf24250ef1b13b23eb38ad979c56316abb (24c4eabf24250ef1b13b23eb38ad979c56316abb)

@rust-timer
Copy link
Collaborator

Queued 24c4eabf24250ef1b13b23eb38ad979c56316abb with parent dfd7b8d, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (24c4eabf24250ef1b13b23eb38ad979c56316abb): comparison url.

Summary: This change led to significant regressions 😿 in compiler performance.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 11, 2021
@cjgillot
Copy link
Contributor

@Aaron1011 the changes LGTM. Do you have an idea where the perf regression could come from?

@eddyb
Copy link
Member

eddyb commented Jul 18, 2021

Doesn't this PR run into the same issue described in #74283 (comment) ?

Even if you use static instead of const, the codegen for various closures will still happen in rustc_interface (i.e. the crate containing the default providers static), instead of the original crate, leading to performance regressions.

@eddyb
Copy link
Member

eddyb commented Jul 18, 2021

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned cjgillot Jul 18, 2021
@JohnCSimon JohnCSimon 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 Aug 9, 2021
@JohnCSimon
Copy link
Member

Triage:
Returned to the author for merge conflicts.

@camelid camelid 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 29, 2021
@JohnCSimon
Copy link
Member

Triage:
@Aaron1011 fyi merge conflicts

@JohnCSimon JohnCSimon 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 3, 2021
@JohnCSimon JohnCSimon 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 19, 2021
@JohnCSimon JohnCSimon 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 8, 2021
@jyn514
Copy link
Member

jyn514 commented Nov 9, 2021

I'm going to close this for now since there are performance regressions and I'm unclear whether they're possible to fix: #87040 (comment)

@jyn514 jyn514 closed this Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) perf-regression Performance regression. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

None yet