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

Don't perform any new queries while reading a query result on disk #91919

Merged
merged 5 commits into from Jan 8, 2022

Conversation

Aaron1011
Copy link
Member

@Aaron1011 Aaron1011 commented Dec 14, 2021

In addition to being very confusing, this can cause us to add dep node edges between two queries that would not otherwise have an edge.

We now panic if any new dep node edges are created during the deserialization of a query result. This requires serializing the full AdtDef to disk, instead of just serializing the DefId and invoking the adt_def query during deserialization.

I'll probably split this up into several smaller PRs for perf runs.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 14, 2021
@rust-highfive
Copy link
Collaborator

r? @jackh726

(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 Dec 14, 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 Dec 14, 2021
@bors
Copy link
Contributor

bors commented Dec 14, 2021

⌛ Trying commit 193372013836ac4e5940ebfe088bdd44cdcee7e5 with merge 535f5db4e39c1538a165cd4e32d36e737c439cfd...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Dec 14, 2021

💔 Test failed - checks-actions

@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 Dec 14, 2021
@rust-log-analyzer

This comment has been minimized.

@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

@bors
Copy link
Contributor

bors commented Dec 14, 2021

⌛ Trying commit b9c62879fd4c4a31eb2fa8606dd0e2351dba51fd with merge 861c72a96000618f65e5a7f8cf224b77be30b4fc...

@bors
Copy link
Contributor

bors commented Dec 14, 2021

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

@rust-timer
Copy link
Collaborator

Queued 861c72a96000618f65e5a7f8cf224b77be30b4fc with parent 404c847, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (861c72a96000618f65e5a7f8cf224b77be30b4fc): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

  • Very large improvement in instruction counts (up to -24.9% on incr-unchanged builds of issue-46449)
  • Very large regression in instruction counts (up to 16.1% on incr-full builds of webrender-wrench)

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 try 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. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Dec 14, 2021
@teor2345
Copy link
Contributor

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

  • Very large improvement in instruction counts (up to -24.9% on incr-unchanged builds of issue-46449)
  • Very large regression in instruction counts (up to 16.1% on incr-full builds of webrender-wrench)

Seems like an overall performance win, except for a few large outliers.

@Aaron1011
Copy link
Member Author

The perf results are very similar to PR #91924 which was split out from this one, so I think that PR is responsible for all of the significant performance changes.

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 28, 2021
@apiraino
Copy link
Contributor

Beta backport declined as per compiler team discussion on Zulip

@rustbot label -beta-nominated

@rustbot rustbot removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 30, 2021
let mut deps = TaskDeps::default();
deps.read_allowed = false;
let deps = Lock::new(deps);
K::with_deps(Some(&deps), op)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we prefer to use an enum for deps:

enum TaskDepsRef<'a> {
  Allow(&'a Lock<TaskDeps>),
  Ignore,
  Forbid,
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Opened #92681

// are created during deserialization. See the docs of that method for more
// details.
let result = dep_graph
.with_query_deserialization(|| query.try_load_from_disk(tcx, prev_dep_node_index));
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can even forbid queries inside the invocation code. Can this call be moved around the NotYetStarted branch of try_execute_query? It's not supposed to invoke any user-provided code directly, only call into the DepGraph to setup a TaskDeps.

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 this earlier, but there are some invocations of def_span within the query infrastructure itself. I think those could be removed in a follow-up PR, since this PR should catch almost all of the cases.

pub fn with_query_deserialization<OP, R>(&self, op: OP) -> R
where
OP: FnOnce() -> R,
{
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we add a fast path if the dep-graph is disabled?

Copy link
Member

Choose a reason for hiding this comment

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

This should never be called, if the dep-graph is disabled, right? Maybe we could add a debug assertion that the dep-graph is indeed enabled.

@michaelwoerister
Copy link
Member

This looks good to me now. @cjgillot's comments make sense to me, but I'd be fine with addressing them at a later point in time.

@jackh726
Copy link
Member

jackh726 commented Jan 6, 2022

r? @michaelwoerister

@michaelwoerister
Copy link
Member

Let's get this merged.

@bors r+

@bors
Copy link
Contributor

bors commented Jan 7, 2022

📌 Commit 27ed52c 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 Jan 7, 2022
@bors
Copy link
Contributor

bors commented Jan 8, 2022

⌛ Testing commit 27ed52c with merge a7e2e33...

@bors
Copy link
Contributor

bors commented Jan 8, 2022

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing a7e2e33 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 8, 2022
@bors bors merged commit a7e2e33 into rust-lang:master Jan 8, 2022
@rustbot rustbot added this to the 1.60.0 milestone Jan 8, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a7e2e33): comparison url.

Summary: This benchmark run did not return any relevant changes.

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

@rustbot label: -perf-regression

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

None yet