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

[WIP] traits/select: use global vs per-infcx caches more uniformly. #69294

Closed
wants to merge 3 commits into from

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Feb 19, 2020

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 DepNodes, 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 DepNodes 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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 19, 2020
@eddyb

This comment has been minimized.

@rust-timer

This comment has been minimized.

@bors

This comment has been minimized.

@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2020

@Mark-Simulacrum Ugh, I was hoping to do this on top of 58b8343, before all of the recent rustc::{infer,traits} changes, but bors seems to want to merge against current master.

@eddyb eddyb force-pushed the trait-cache-streamline branch from 2a24386 to 6a51d66 Compare February 19, 2020 18:15
@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2020

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Feb 19, 2020

⌛ Trying commit 6a51d66 with merge a540ddc...

bors added a commit that referenced this pull request Feb 19, 2020
[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
@Mark-Simulacrum
Copy link
Member

Ugh, I was hoping to do this on top of 58b8343, before all of the recent rustc::{infer,traits} changes, but bors seems to want to merge against current master.

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).

@bors
Copy link
Contributor

bors commented Feb 19, 2020

☀️ Try build successful - checks-azure
Build commit: a540ddc (a540ddca4b5ca4451bed53f0b13b03b5db95c9ec)

@rust-timer
Copy link
Collaborator

Queued a540ddc with parent 7710ae0, future comparison URL.

@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2020

@Mark-Simulacrum I was shocked at how far down I had to go in git log to find the PRs I wanted to base myself just before, I don't think I could seriously consider reverting all of them, heh.

@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Feb 19, 2020

In theory git revert -m1 $(git log <base PR bors commit> --author=bors --format %H) should work, but I haven't tested :)

@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2020

It's more that I would find that excessive and it would make a mess of the PR.

@eddyb
Copy link
Member Author

eddyb commented Feb 20, 2020

Surprised this is already a win, this is good news (results are available, idk why the bot didn't post another comment).

@eddyb eddyb force-pushed the trait-cache-streamline branch from 6a51d66 to 2bc133c Compare February 24, 2020 17:21
Comment on lines -1288 to +1280
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(),
Copy link
Member Author

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.

@nikomatsakis
Copy link
Contributor

BTW I'm planning to review this today or tomorrow

Copy link
Contributor

@nikomatsakis nikomatsakis left a 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.

&self.infcx.selection_cache
};

cache.hashmap.borrow().get(&param_env.and(*trait_ref)).map(|v| v.get(tcx))
Copy link
Contributor

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 {
Copy link
Contributor

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

Copy link
Contributor

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...

Copy link
Member Author

@eddyb eddyb Mar 2, 2020

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).

@Dylan-DPC-zz Dylan-DPC-zz 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 Mar 11, 2020
@bors
Copy link
Contributor

bors commented Mar 14, 2020

☔ The latest upstream changes (presumably #69076) made this pull request unmergeable. Please resolve the merge conflicts.

@nikomatsakis
Copy link
Contributor

@eddyb is this PR considered "eligible to merge" or is it blocked on something?

@eddyb
Copy link
Member Author

eddyb commented Apr 6, 2020

@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 eddyb added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 6, 2020
@eddyb eddyb marked this pull request as draft April 10, 2020 20:33
@Dylan-DPC-zz
Copy link

Dylan-DPC-zz commented Sep 11, 2020

@eddyb the grants PR has been merged, is there anything else this is blocked on?

@nikomatsakis
Copy link
Contributor

I'm going to close this PR for inactivity. @eddyb re-open if you want when you think it's ready to go forward

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked Status: Blocked on something else such as an RFC or other implementation work.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants