-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Implement normalize_erasing_regions queries in terms of 'try' version #91672
Implement normalize_erasing_regions queries in terms of 'try' version #91672
Conversation
@@ -36,6 +37,7 @@ note: ...which requires caching mir of `FooDefault::BAR` for CTFE... | |||
LL | const BAR: u32 = DEFAULT_REF_BAR; | |||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |||
= note: ...which requires normalizing `DEFAULT_REF_BAR`... | |||
= note: ...which requires normalizing `DEFAULT_REF_BAR`... |
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.
What can we do about this duplication? We can't just remove the query description of normalize_erasing... queries.
normalize_after_erasing_regions(tcx, goal) | ||
|
||
let (param_env, goal) = goal.into_parts(); | ||
tcx.try_normalize_erasing_regions(param_env, goal).unwrap_or_else(|_| 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.
Wasn't sure whether it's better to use try_normalize_generic_arg_after_erasing_regions
here directly or implement this as here (and go through the visitor). The latter would lead to more caching, which might be beneficial when calling normalize_erasing_regions
in later stages of compilation, or we might just cache stuff we don't need and also have the cost of traversing the visitor on each call, not sure.
☔ The latest upstream changes (presumably #91665) made this pull request unmergeable. Please resolve the merge conflicts. |
28bb188
to
59a33c2
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 59a33c262b0ff37963f1f55b2008f3f4c716c601 with merge a16ff5c167cd59dbef8e0d6e84cf32aeb4a97a51... |
☀️ Try build successful - checks-actions |
Queued a16ff5c167cd59dbef8e0d6e84cf32aeb4a97a51 with parent 600820d, future comparison URL. |
Finished benchmarking commit (a16ff5c167cd59dbef8e0d6e84cf32aeb4a97a51): comparison url. Summary: This change led to small relevant mixed results 🤷 in compiler performance.
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 @bors rollup=never |
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.
Thought: Do we even need the normalize_generic_arg_after_erasing_regions
and normalize_mir_const_after_erasing_regions
queries? Seems like we can just make them either inherent methods on TyCtxt<'tcx>
or, better, just call try_*
with a bug!()
in the one they're called each...
@jackh726 Can you request another perf-run, please? |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 009e83488716f90c1ec7d9d8a635d2e6bc2e94c9 with merge 763e1db0840ce350629924afc881ea361b2192a2... |
☀️ Try build successful - checks-actions |
Queued 763e1db0840ce350629924afc881ea361b2192a2 with parent 0b42dea, future comparison URL. |
Finished benchmarking commit (763e1db0840ce350629924afc881ea361b2192a2): comparison url. Summary: This benchmark run did not return any relevant changes. 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 |
Mild perf win but simpler API regardless. @bors r+ |
@jackh726 Small problem here, I deleted the branch on my machine once it was r+'ed. I'm unable to recover the branch from my fork on github. Are there other options besides opening a new PR? |
nvm, fortunately you can also resolve conflicts directly in github. |
Github says the branch still exists on your remote. You should be able to fetch it it and then create a branch from the remote ref. |
@the8472 I cloned the remote repo, but it only had a single master branch for some reason. What do you mean by fetching the remote branch? |
Ok nvm, thats a git command I didnt know about. |
This comment has been minimized.
This comment has been minimized.
That breaks the no-merge policy, you have to rebase onto current master instead. |
f84942c
to
399ab40
Compare
Thanks. |
@jackh726 Can you r+ this again, please? |
@bors r+ |
📌 Commit 399ab40 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9b45f04): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
That's... weird |
This seems likely to be noise as a result of the issue tracked in rust-lang/rustc-perf#1126 -- marking as triaged, not something we should address directly. @rustbot label +perf-regression-triaged |
Attempt to lessen performance regression caused by #91255
r? @jackh726