-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Take impl Into<DefId>
for query methods on TyCtxt
#70961
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @Zoxc |
fn inner(this: TyCtxtAt<$tcx>, key: DefId) -> $V { | ||
get_query::<queries::$name<'_>, _>(this.tcx, this.span, key) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is get_query
inlined? This does nothing otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was an attempt to address @Zoxc's comment. I don't understand why it's beneficial for the caller of get_query
to be monomorphic, since it is #[inline(never)]
. Perhaps I misunderstood? ensure_query
is not #[inline(never)]
at the moment, however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IFAIK, the LLVM codegen of the {get,force,ensure}_query
functions is responsible for most of the compile time for librustc_middle. It happens once for each of the 170 queries. By making the caller generic, part of this codegen may be replicated in caller crates. This would have a serious impact on rustc's compile time. Please correct me if #[inline(never)]
is enough to prevent this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wrapper functions are already #[inline(always)]
so they would be codegen'd cross-crate even when not generic.
(TyCtxtAt<$tcx:tt>, $(#[$attr:meta])* $name:ident(DefId) -> $V:ty) => { | ||
$(#[$attr])* | ||
#[inline(always)] | ||
pub fn $name(self, key: impl Into<DefId>) -> $V { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make a type macro and use that to pattern-match on just the key type?
I think we can just use .into()
in all methods, as it will compile to a noop when the types are the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea. It won't work if we do want a monomorphic helper function, but maybe we don't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_query
is #[inline(never)]
(I just checked) so you don't need this wrapper.
6ed806b
to
e1de311
Compare
Per rust-lang/team#316, r? @eddyb -- let me know @eddyb if you'd prefer someone else. |
e1de311
to
5ff63c9
Compare
@eddyb The last two commits implement your suggestion for simplifying the macro and replace |
src/librustc_middle/ty/query/mod.rs
Outdated
pub trait IntoQueryParam<P> { | ||
fn into_query_param(self) -> P; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case there was any confusion, "sealing" works like this:
mod sealed {
pub trait IntoQueryParam<P> {
fn into_query_param(self) -> P;
}
}
Then you can refer to it as sealed::IntoQueryParam
, and as long as sealed
remains private, and you don't reexport IntoQueryParam
somewhere, it should be impossible to implement or import the trait, outside of the parent module of the mod sealed
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I thought you meant the super-trait patten that's in the API guidelines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ecstatic-morse ah I see, that pattern uses a sealed trait for a specific purpose.
Or maybe I'm the only person referring to "pub
but in a private mod
" as "sealed".
LGTM, but before I approve: @bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit 3ac350d8349c9fbb921c9b9ac7f01cf5c8869759 with merge bca1f3800d78009dd283fff15b216fa1edf32996... |
pub fn $name(self, key: $K) { | ||
ensure_query::<queries::$name<'_>, _>(self.tcx, key) | ||
pub fn $name(self, key: query_helper_param_ty!($($K)*)) { | ||
ensure_query::<queries::$name<'_>, _>(self.tcx, key.into_query_param()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, are these changes needed? "ensuring" should be rather rare AFAIK?
…e-local-def-id, r=eddyb rustc_middle: return `LocalDefId` where possible in hir::map module This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`: * opt_local_def_id_from_node_id * opt_local_def_id * body_owner_def_id * local_def_id_from_node_id * get_parent_id This is another step in the right direction for rust-lang#70853 This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for rust-lang#70956 or rust-lang#70961 (or some other form it) to land first.
…dle-local-def-id, r=eddyb rustc_middle: return `LocalDefId` where possible in hir::map module This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`: * opt_local_def_id_from_node_id * opt_local_def_id * body_owner_def_id * local_def_id_from_node_id * get_parent_id This is another step in the right direction for rust-lang#70853 This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for rust-lang#70956 or rust-lang#70961 (or some other form it) to land first.
☀️ Try build successful - checks-azure |
Queued bca1f3800d78009dd283fff15b216fa1edf32996 with parent 9682f0e, future comparison URL. |
Finished benchmarking try commit bca1f3800d78009dd283fff15b216fa1edf32996, comparison URL. |
@ecstatic-morse @eddyb is the performance good enough for this to land? |
@marmeladema Too slow IMO. We'll need to micro-optimize or abandon this idea. |
} | ||
|
||
impl IntoQueryParam<DefId> for LocalDefId { | ||
fn into_query_param(self) -> DefId { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try adding #[inline(always)]
to this (and to_def_id
if it doesn't have it).
Although, wait, are we using this at all now? Is the slowdown just from going through the noop impl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's used exactly once as a test 6e5a210. I'm skeptical that this will help, since no into_query_param
call appears in the optimized binary, and the DefId
queries I looked at inline down to get_query
. There's no predicting the optimizer though.
3ac350d
to
04c91a0
Compare
@bors try |
Awaiting bors try build completion |
⌛ Trying commit 04c91a0 with merge 4db70335bb09ba1a20ddee9e96cc14d6bb67b630... |
☀️ Try build successful - checks-azure |
Queued 4db70335bb09ba1a20ddee9e96cc14d6bb67b630 with parent e82734e, future comparison URL. |
Finished benchmarking try commit 4db70335bb09ba1a20ddee9e96cc14d6bb67b630, comparison URL. |
Heh that's what it was! r=me if there is no disagreement about doing this. |
Eh let's just do it. @bors r+ |
📌 Commit 04c91a0 has been approved by |
☀️ Test successful - checks-azure |
Alternative implementation of #70956. cc #70853.