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

Replace DepKind by trait objects #78314

Closed
wants to merge 18 commits into from
Closed

Conversation

cjgillot
Copy link
Contributor

Most of the code depending on DepNodes just matches on their DepKind.
This PR replaces those matches by trait objects, using a unit struct for each DepKind variant.

Everything still has to be declared inside rustc_middle, but the need for the macros is significantly reduced.
I would have preferred defining the trait inside rustc_query_system, but this needs more work.

cc @Julian-Wollersberger

Based on #77830 for the first few commits.

@rust-highfive
Copy link
Collaborator

r? @estebank

(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 Oct 24, 2020
Copy link
Contributor

@Julian-Wollersberger Julian-Wollersberger left a comment

Choose a reason for hiding this comment

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

Thanks for cc-ing me. I left some nitpicks.

I can't comment on the larger picture though, because it's still to complicated for me after two weeks working in the query system. (It seems like I have chosen the worst part a beginner can work on. But at least it's a challenge!)

So, I'm curious what you envision the next steps to be here.
It seems orthogonal to what I tried in in #78275.


$(
#[allow(non_camel_case_types)]
pub struct $variant;
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be good to rename $variant to $name here to be consistent with the proc macro and compiler/rustc_middle/src/ty/query/mod.rs
Specifically the inconsistency with the line $(impl dep_kind::$name { bothers me.

Comment on lines 237 to 242
pub mod dep_kind {
$(
#[allow(non_camel_case_types)]
#[derive(Debug)]
pub struct $variant;
)*
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd move this struct to define_dep_kinds.

@@ -24,14 +25,14 @@ pub type PreviousDepGraph = rustc_query_system::dep_graph::PreviousDepGraph<DepK
pub type SerializedDepGraph = rustc_query_system::dep_graph::SerializedDepGraph<DepKind>;

impl rustc_query_system::dep_graph::DepKind for DepKind {
Copy link
Contributor

Choose a reason for hiding this comment

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

All these different types that are named DepKind get confusing.
Maybe name it DynDepKind?

@@ -103,95 +120,136 @@ macro_rules! contains_eval_always_attr {
($($attr:ident $(($($attr_args:tt)*))* ),*) => ({$(is_eval_always_attr!($attr) | )* false});
}

macro_rules! define_dep_nodes {
macro_rules! define_dep_kinds {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd move this into a new file dep_kind.rs.

@@ -765,7 +753,7 @@ impl<'a, 'tcx> Decodable<CacheDecoder<'a, 'tcx>> for &'tcx [Span] {
//- ENCODING -------------------------------------------------------------------

/// This trait is a hack to work around specialization bug #55243.
trait OpaqueEncoder: Encoder {
pub trait OpaqueEncoder: Encoder {
Copy link
Contributor

@Julian-Wollersberger Julian-Wollersberger Oct 24, 2020

Choose a reason for hiding this comment

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

Why move the trait to make it private and then make it public again?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This trait is a hack. Ideally, all E: OpaqueEncoder should be E = opaque::Encoder. It needs to be public because it appears in CacheEncoder, which is public because it appears in DepKindTrait. Removing E: OpaqueEncoder from CacheEncoder definition breaks specialization (I don't know why).

Comment on lines 259 to 262
// FIXME: This match is just a workaround for incremental bugs and should
// be removed. https://github.com/rust-lang/rust/issues/62649 is one such
// bug that must be fixed before removing this.
match self.index() {
Copy link
Contributor

Choose a reason for hiding this comment

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

All this workaround code is now duplicated for every dep_kind::$variant. That's not good for compile times.
What's the reason for doing this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree this was a bad idea.

@@ -481,51 +459,28 @@ pub fn rustc_queries(input: TokenStream) -> TokenStream {
if modifiers.eval_always {
attributes.push(quote! { eval_always });
};
// Pass on the cache modifier
if modifiers.cache.is_some() {
attributes.push(quote! { cached });
Copy link
Contributor

Choose a reason for hiding this comment

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

Where is this attribute used? I can't find it.

EDIT: Fount it in encode_query_results. Can you add a comment documenting this dependency?

$($variant),*
}

pub static DEP_KINDS: &[DepKind] = &[ $(&dep_kind::$variant),* ];
Copy link
Contributor

Choose a reason for hiding this comment

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

This is an interesting trick! ^^

@@ -304,6 +526,271 @@ rustc_dep_node_append!([define_dep_nodes!][ <'tcx>
[] CompileCodegenUnit(Symbol),
]);

impl DepKindTrait for dep_kind::Null {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't these traits be implemented by the macro, by adding them to the
rustc_dep_node_append!([define_dep_kinds!][ <'tcx> ]); invokation,
similarly to how it's done for define_dep_nodes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Those DepKinds are not associated to queries. This requires a special workaround for force_from_dep_node and try_load_from_on_disk_cache.

@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 Oct 24, 2020
@jonas-schievink
Copy link
Contributor

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Oct 24, 2020

⌛ Trying commit 41720af with merge ca3c21d7ea44af5f9bbe58698ce3fd2e5cd675bf...

@bors
Copy link
Contributor

bors commented Oct 24, 2020

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

@rust-timer
Copy link
Collaborator

Queued ca3c21d7ea44af5f9bbe58698ce3fd2e5cd675bf with parent 89fdb30, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (ca3c21d7ea44af5f9bbe58698ce3fd2e5cd675bf): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

@cjgillot cjgillot closed this Nov 1, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 8, 2021
Access query (DepKind) metadata through fields

This refactors the access to query definition metadata (attributes such as eval always, anon, has_params) and loading/forcing functions to generate a number of structs, instead of matching on the DepKind enum. This makes access to the fields cheaper to compile. Using a struct means that finding the metadata for a given query is just an offset away; previously the match may have been compiled to a jump table but likely not completely inlined as we expect here.

A previous attempt explored a similar strategy, but using trait objects in rust-lang#78314 that proved less effective, likely due to higher overheads due to forcing dynamic calls and poorer cache utilization (all metadata is fairly densely packed with this PR).
@cjgillot cjgillot deleted the ddk branch September 21, 2021 16:11
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) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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.

8 participants