Discard region-related bounds from ParamEnv when predicate is global

[Aaron1011]

This allows us to use global caches in more places, since we can drop
predicates containing inference variables.

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit b0d99cc5170616b695c10baa68699749e5368e6a with merge 6d83257505f822f6661144e98f829b369a69241a...

[bors]

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

[rust-timer]

Queued 6d83257505f822f6661144e98f829b369a69241a with parent 2595d03, future comparison URL.

[rust-timer]

Finished benchmarking commit (6d83257505f822f6661144e98f829b369a69241a): comparison url.

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

• Large improvement in instruction counts (up to -3.6% on full builds of style-servo)
• Very large regression in instruction counts (up to 133.2% on incr-unchanged builds of ctfe-stress-4)

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

[petrochenkov]

r? rust-lang/traits

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit b0d99cc5170616b695c10baa68699749e5368e6a with merge 80c545594ea7467b84473666e8fe544146524e26...

[jackh726]

r=me after perf

[bors]

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

[rust-timer]

Queued 80c545594ea7467b84473666e8fe544146524e26 with parent 41c3017, future comparison URL.

[rust-timer]

Finished benchmarking commit (80c545594ea7467b84473666e8fe544146524e26): comparison url.

Summary: This change led to large relevant improvements 🎉 in compiler performance.

• Large improvement in instruction counts (up to -3.6% on full 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.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[Aaron1011]

I'd like to add some tests, and get some additional review, before we merge this. I'm fairly certain that my strategy is sound, but anything involving regions can get pretty tricky.

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 835fc8a with merge 9e2081f43f6c3aace69b3469c6ed56cafe0e02a5...

[bors]

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

[rust-timer]

Queued 9e2081f43f6c3aace69b3469c6ed56cafe0e02a5 with parent 84f962a, future comparison URL.

[rust-timer]

Finished benchmarking commit (9e2081f43f6c3aace69b3469c6ed56cafe0e02a5): comparison url.

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

• Large improvement in instruction counts (up to -3.7% on full builds of style-servo)
• Small regression in instruction counts (up to 0.3% on incr-unchanged builds of helloworld)

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

[nnethercote]

@Aaron1011: just to clarify, is this still waiting on the additional tests? Thanks.

[Aaron1011]

After thinking about this more, I've become significantly less confident that this is actually sound. I'm going to do some additional investigation this week.

[carols10cents]

@Aaron1011 if there's anything I can do to help, please let me know! ❤️

[Aaron1011]

After thinking about this more, I think the root of the problem is the way that we canonicalize our obligation to create a CanonicalPredicateGoal when invoking evaluate_obligation. Currently, we replace all regions (except for 'static) with canonical region variables, which then get instantiated to inference variables in the implementation of evaluate_obligation. This allows many different usages of regions (region variables, early-bound, late-bound, etc) in the input to all end up being converted to the same CanonicalPredicateGoal.

This has the advantage of allowing us to re-use the same query invocation for (potentially) many different inputs - the evaluate_obligation query is (mainly) used to see if we can get EvaluatedToOk and therefore skip additional region processing. However, this ends up hurting our caching ability within the evaluate_obligation query - having inference variables in our ParamEnv means that we can't use the global cache.

Additionally, replacing non-region-variables (e.g. early-bound or late-bound regions) with region variables seems somewhat questionable. If we have two distinct ReEarlyBounds in our ParamEnv, then the region inference code will never let us 'equate' them. However, after instantiation of the canonicalized query, we could end up successfully 'equating' them (since they have become region inference variables), and never notifying the caller of this.

I think the solution is to change how we handle canonicalizing of the ParamEnv (and maybe the Predicate being evaluated as well). Instead of converting resolved regions to region variables (by way of canonical region variables), we should try to 'anonymize' regions based on where they occur. For example, a predicate like Outlives(MyType<'a, 'b>, 'b) could be 'anonymized' to Outlives(MyType<'0, '1>, '1) during instantiation. Here, '0 and '1 are early-bound regions, not region variables. This will improve our caching ability (since the ParamEnv should almost never end up with region variables), and avoid any potential problems caused by the ability to 'equate' region variables corresponding to two distinct early-bound regions.

[jackh726]

If we have two distinct ReEarlyBounds in our ParamEnv, then the region inference code will never let us 'equate' them.

I don't think that's true...you can always end up with <'a , 'b: 'a>, right? 'a and 'b are "distinct", but can be equated.

I think the solution is to change how we handle canonicalizing of the ParamEnv (and maybe the Predicate being evaluated as well). Instead of converting resolved regions to region variables (by way of canonical region variables), we should try to 'anonymize' regions based on where they occur.

This isn't a bad idea. I could imagine that treating early bound lifetimes as a special case, like static, isn't the worst idea.

[Aaron1011]

I don't think that's true...you can always end up with <'a , 'b: 'a>, right? 'a and 'b are "distinct", but can be equated.

If you had that to start off with, then yes. However, if I have fn foo<'a, 'b>, then the region variables introduced for 'a and 'b could end up getting equated.

[jackh726]

Yes, but I don't think there's a way to avoid that; it's not as though we check if regions could be related before adding constraints.

[oli-obk]

and never notifying the caller of this.

I thought the query returned region obligations that need to hold in order for its result to be valid. So you'd actually get equate-obligations for those regions and then reject them because at this point you know the real regions.

maybe we need two kinds of canonicalized regions. Ones that are checked immediately via the ParamEnv, and ones that just generate obligations when compared without knowledge about their relation.

[JohnCSimon]

@Aaron1011
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive