Uh oh!
There was an error while loading. Please reload this page.
Implement normalize_erasing_regions queries in terms of 'try' version - #91672
Conversation
There was a problem hiding this comment.
What can we do about this duplication? We can't just remove the query description of normalize_erasing... queries.
There was a problem hiding this comment.
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.
bors
commented
Dec 8, 2021
☔ The latest upstream changes (presumably #91665) made this pull request unmergeable. Please resolve the merge conflicts. |
28bb188 to
59a33c2Comparethe8472
commented
Dec 9, 2021
@bors try @rust-timer queue |
rust-timer
commented
Dec 9, 2021
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
Dec 9, 2021
⌛ Trying commit 59a33c262b0ff37963f1f55b2008f3f4c716c601 with merge a16ff5c167cd59dbef8e0d6e84cf32aeb4a97a51... |
bors
commented
Dec 9, 2021
☀️ Try build successful - checks-actions |
rust-timer
commented
Dec 9, 2021
Queued a16ff5c167cd59dbef8e0d6e84cf32aeb4a97a51 with parent 600820d, future comparison URL. |
rust-timer
commented
Dec 9, 2021
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 |
jackh726
left a comment
There was a problem hiding this comment.
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...
b-naber
commented
Dec 10, 2021
@jackh726 Can you request another perf-run, please? |
jackh726
commented
Dec 10, 2021
@bors try @rust-timer queue |
rust-timer
commented
Dec 10, 2021
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
Dec 10, 2021
⌛ Trying commit 009e83488716f90c1ec7d9d8a635d2e6bc2e94c9 with merge 763e1db0840ce350629924afc881ea361b2192a2... |
bors
commented
Dec 10, 2021
☀️ Try build successful - checks-actions |
rust-timer
commented
Dec 10, 2021
Queued 763e1db0840ce350629924afc881ea361b2192a2 with parent 0b42dea, future comparison URL. |
rust-timer
commented
Dec 10, 2021
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 |
jackh726
commented
Dec 10, 2021
Mild perf win but simpler API regardless. @bors r+ |
b-naber
commented
Dec 13, 2021
@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? |
b-naber
commented
Dec 13, 2021
nvm, fortunately you can also resolve conflicts directly in github. |
the8472
commented
Dec 13, 2021
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. |
b-naber
commented
Dec 13, 2021
@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? |
b-naber
commented
Dec 13, 2021
Ok nvm, thats a git command I didnt know about. |
This comment has been minimized.
This comment has been minimized.
the8472
commented
Dec 13, 2021
That breaks the no-merge policy, you have to rebase onto current master instead. |
f84942c to
399ab40Compareb-naber
commented
Dec 13, 2021
Thanks. |
b-naber
commented
Dec 16, 2021
@jackh726 Can you r+ this again, please? |
jackh726
commented
Dec 16, 2021
@bors r+ |
bors
commented
Dec 16, 2021
📌 Commit 399ab40 has been approved by |
bors
commented
Dec 17, 2021
bors
commented
Dec 17, 2021
☀️ Test successful - checks-actions |
rust-timer
commented
Dec 17, 2021
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 |
rylev
commented
Dec 21, 2021
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