-
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
[WIP] traits/select: use global vs per-infcx caches more uniformly. #69294
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@Mark-Simulacrum Ugh, I was hoping to do this on top of 58b8343, before all of the recent |
2a24386
to
6a51d66
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion |
[WIP] traits/select: use global vs per-infcx caches more uniformly. ~~*Note: this is based on an older `master` to avoid perf interference before #67953 (comment) is resolved.*~~ **EDIT**: sadly not workable due #69294 (comment). So far this PR only has the first couple steps towards making the decision of which cache ("global" vs "per-`InferCtxt`") to use for trait evaluation/selection, only once (at the time of checking the cache). The goal here is to actually make per-`InferCtxt` caches not track `DepNode`s, and maybe even enforce that once `SelectionContext::in_task` is entered, the `InferCtxt` is effectively unused. My assumption is that if you *need* inference variables in your cache key (i.e. `ParamEnv` and/or `PolyTraitPredicate`) to ever end up doing anything "non-global", and you can't get there from a "global cache key" (which would still use `DepNode`s and `in_task` etc.). Perhaps another path forward is to redirect "global cache keys" to a query, but I'm not sure how that would handle cycles (badly?), and it feels like stepping on Chalk's toes. r? @nikomatsakis cc @rust-lang/wg-traits @Zoxc @michaelwoerister
AFAIK, if you really want this you can add revert commits to this branch for master's commits since then and then compare with an older base commit (vs. using the link perf auto-generates). |
☀️ Try build successful - checks-azure |
Queued a540ddc with parent 7710ae0, future comparison URL. |
@Mark-Simulacrum I was shocked at how far down I had to go in |
In theory |
It's more that I would find that excessive and it would make a mess of the PR. |
Surprised this is already a win, this is good news (results are available, idk why the bot didn't post another comment). |
6a51d66
to
2bc133c
Compare
Ok(Some(SelectionCandidate::ParamCandidate(trait_ref))) => { | ||
!trait_ref.skip_binder().input_types().any(|t| t.walk().any(|t_| t_.is_ty_infer())) | ||
} | ||
Ok(Some(SelectionCandidate::ParamCandidate(trait_ref))) => !trait_ref.needs_infer(), |
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 is a fix for #55258 (comment), I should make a separate commit but I didn't want to lose track of this.
BTW I'm planning to review this today or tomorrow |
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 all makes a lot of sense to me thus far. Sorry for being a bit slow.
src/librustc_infer/traits/select.rs
Outdated
&self.infcx.selection_cache | ||
}; | ||
|
||
cache.hashmap.borrow().get(¶m_env.and(*trait_ref)).map(|v| v.get(tcx)) |
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.
to be clear, this commit is just a "logical cleanup", right?
} | ||
} | ||
// HACK(eddyb) never cache overflow (this check used to be global-only). | ||
if let Err(Overflow) = candidate { |
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.
with the exception of this tiny logic change, I guess
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.
I can't really think why we would want to cache overflow locally anyhow, that seems like a bug...
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.
Pfft, that's nothing, here's something more fun: I don't think we ever use the local caches except for the intercrate
mode, because we're doing freshening all the time.
So we could put intercrate
in Reveal
or w/e then replace freshening with canonicalization, and have only global caching (either that or I'm seriously misunderstanding the implementation).
☔ The latest upstream changes (presumably #69076) made this pull request unmergeable. Please resolve the merge conflicts. |
@eddyb is this PR considered "eligible to merge" or is it blocked on something? |
@nikomatsakis This is waiting for M1 from w3f/General-Grants-Program#261 (i.e. self-profiling integration for the trait system), so that we can measure the impact of this. I'll likely open a PR for that soon. |
@eddyb the grants PR has been merged, is there anything else this is blocked on? |
I'm going to close this PR for inactivity. @eddyb re-open if you want when you think it's ready to go forward |
Note: this is based on an olderEDIT: sadly not workable due #69294 (comment).master
to avoid perf interference before #67953 (comment) is resolved.So far this PR only has the first couple steps towards making the decision of which cache ("global" vs "per-
InferCtxt
") to use for trait evaluation/selection, only once (at the time of checking the cache).The goal here is to actually make per-
InferCtxt
caches not trackDepNode
s, and maybe even enforce that onceSelectionContext::in_task
is entered, theInferCtxt
is effectively unused.My assumption is that if you need inference variables in your cache key (i.e.
ParamEnv
and/orPolyTraitPredicate
) to ever end up doing anything "non-global", and you can't get there from a "global cache key" (which would still useDepNode
s andin_task
etc.).Perhaps another path forward is to redirect "global cache keys" to a query, but I'm not sure how that would handle cycles (badly?), and it feels like stepping on Chalk's toes.
r? @nikomatsakis cc @rust-lang/wg-traits @Zoxc @michaelwoerister