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.

Sign up for GitHub

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

Jump to bottom

Add fast path to is_descendant_of #91043

Merged
merged 2 commits into from
Nov 29, 2021
Merged

Add fast path to is_descendant_of #91043

merged 2 commits into from
Nov 29, 2021

Conversation

camsteffen
Copy link
Contributor

No description provided.

@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 Nov 19, 2021
@cjgillot
Copy link
Contributor

cjgillot commented Nov 19, 2021 •
edited
Loading

I think we have an invariant that either expn_id == ExpnId::root() or expn_id.krate == self.expn_data(expn_id).parent.krate? I'm not sure that it always hold and that we enforce it. This would allow another fast path if expn_id.krate != ancestor.krate.

@camsteffen
Copy link
Contributor Author

I don't think that is true because a macro can have a nested macro call to an external crate?

@cjgillot
Copy link
Contributor

Macros are expanded from the outer in. ExpnData::parent tracks where the code ends up once expanded, def_site tracks where it was written (possibly in an upstream crate) and call_site where the macro call was written (possibly in a downstream crate).
Hence, even if the nested macro call is to a macro defined in an external crate, this nested macro call is expanded into the crate its parent was expanded into.
Actually, we check that expn_data.parent.krate == LOCAL_CRATE when we assign a LocalExpnId.

@camsteffen
Copy link
Contributor Author

Okay I think I get it, tell me if this sounds right. A stack of nested macro calls are all triggered by one outermost macro call in a particular crate. All the expansions in the stack belong to that crate.

Should I modify HygieneData::is_descendant_of too?

@cjgillot
Copy link
Contributor

Indeed, we should probably make every caller benefit from the optimization.

@camsteffen camsteffen changed the title Add fast path to ExpnId::is_descendant Add fast path to is_descendant_of Nov 19, 2021
@petrochenkov petrochenkov self-assigned this Nov 20, 2021
@jackh726
Copy link
Member

Whoops.

@petrochenkov let me know if your self-assignment was a mistake and I can review

@petrochenkov
Copy link
Contributor

expn_id.krate == self.expn_data(expn_id).parent.krate?

That's not necessarily true if the parent is a root because we don't yet preserve krate IDs for root expansions, but otherwise this should be true.
I'd add an assert for this to the ExpnData-creating function, if possible.

@petrochenkov
Copy link
Contributor

@jackh726
I usually add myself as a second reviewer if I want to be aware of the changes, feel free to review.
(Please don't forget to run perf.)

@camsteffen
Copy link
Contributor 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 Nov 21, 2021
@bors
Copy link
Contributor

bors commented Nov 21, 2021

⌛ Trying commit b708abf68d0f335dbd6b3c9021f68f5d3c99b527 with merge 8cf5997459fd458031256a1986c32a922e0d6c0a...

@bors
Copy link
Contributor

bors commented Nov 21, 2021

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

@rust-timer
Copy link
Collaborator

Queued 8cf5997459fd458031256a1986c32a922e0d6c0a with parent b8e5ab2, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8cf5997459fd458031256a1986c32a922e0d6c0a): comparison url.

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

  • Small improvement in instruction counts (up to -1.1% on incr-unchanged builds of wg-grammar)
  • Small regression in instruction counts (up to 0.5% on incr-patched: println builds of style-servo)

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 removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 21, 2021
@rustbot rustbot added the perf-regression Performance regression. label Nov 21, 2021
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 22, 2021
@petrochenkov
Copy link
Contributor

Looks like a minor improvement.

@petrochenkov
Copy link
Contributor

Could you add

  • an assert checking parent crate equality to fn register_expn_id
  • comments to both versions of fn is_descendant_of telling that the start code is a fast path that allows to avoid taking a lock / going in to the loop below.

@petrochenkov petrochenkov 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 Nov 25, 2021
@camsteffen
Copy link
Contributor Author

I also changed a while to loop since I think it's more readable.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 28, 2021
jackh726
jackh726 reviewed Nov 28, 2021
View reviewed changes
Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

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

I don't think I know this code enough to actually r+ this, so I'll defer to @petrochenkov.

With that being said, the changes here seem okay to me.

compiler/rustc_span/src/hygiene.rs
@@ -1223,6 +1240,7 @@ pub fn register_expn_id(
data: ExpnData,
hash: ExpnHash,
) -> ExpnId {
debug_assert!(data.parent == ExpnId::root() || krate == data.parent.krate);
Copy link
Member

Choose a reason for hiding this comment

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

Should this be a regular assert?

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems fine as is, the assert will be removed anyway when root expansions start keeping their crate IDs.

@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 29, 2021

📌 Commit ac8d514 has been approved by petrochenkov

@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 Nov 29, 2021
@bors
Copy link
Contributor

bors commented Nov 29, 2021

⌛ Testing commit ac8d514 with merge 44723c5...

@bors
Copy link
Contributor

bors commented Nov 29, 2021

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 44723c5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 29, 2021
@bors bors merged commit 44723c5 into rust-lang:master Nov 29, 2021
@rustbot rustbot added this to the 1.59.0 milestone Nov 29, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (44723c5): 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

@rustbot rustbot removed the perf-regression Performance regression. label Nov 29, 2021
@camsteffen camsteffen deleted the descendant-eq branch November 29, 2021 13:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cjgillot cjgillot cjgillot left review comments

@petrochenkov petrochenkov petrochenkov left review comments

@jackh726 jackh726 jackh726 left review comments

Assignees

@petrochenkov petrochenkov

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
Milestone
1.59.0
Development

Successfully merging this pull request may close these issues.

None yet
9 participants
@camsteffen @rust-highfive @cjgillot @jackh726 @petrochenkov @rust-timer @bors @apiraino @rustbot