Merge the two depkind vtables #89978
Conversation
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit daeb774d905256f876441a02b67374f79ee99370 with merge 9311997381062f445ad1b8d25c99e8fc41762ccf... |
|
☀️ Try build successful - checks-actions |
|
Queued 9311997381062f445ad1b8d25c99e8fc41762ccf with parent 12b5bce, future comparison URL. |
|
Finished benchmarking commit (9311997381062f445ad1b8d25c99e8fc41762ccf): comparison url. Summary: This change led to moderate 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 |
rustbot
added
perf-regression
|
Overall looks fine to me -- the performance regressions seem likely to be just reshuffling of optimization choices, and don't seem worth additional investigation in my opinion. There's a bunch of improvements in there as well. If we were to try and investigate I'd suggest splitting this PR up -- I think there's several commits which aren't necessarily tied into the primary goal. I am happy to r=me with the one debug_assert nit fixed. |
|
☔ The latest upstream changes (presumably #89933) made this pull request unmergeable. Please resolve the merge conflicts. |
|
r=me when rebased, I think the perf regression noted here is mostly down to this code being very sensitive and so hard to get just improvements in. The improvements seem larger than the regressions, and this is a good cleanup, so I'm OK proceeding. |
Mark-Simulacrum
added
perf-regression-triaged
|
@bors r=Mark-Simulacrum |
|
📌 Commit b11ec29 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (efd0483): comparison url. Summary: This change led to moderate 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 |
Build the query vtable directly. Continuation of rust-lang#89978. This shrinks the query interface and attempts to reduce the amount of function pointer calls.
|
Marking as triaged per earlier comments, final results seem consistent with earlier ones. @rustbot label +perf-regression-triaged |
The way it is implemented currently try_force_from_dep_node returns true as long as there's a function to force the query. It wasn't this way from the beginning, earlier version was producing forcing result and it was changed in rust-lang#89978, I couldn't find any comments addressing this change. One way it can fail is by failing to recover the query in DepNodeParams::recover - when we are trying to query something that no longer exists in the current environment
The way it is implemented currently try_force_from_dep_node returns true as long as there's a function to force the query. It wasn't this way from the beginning, earlier version was producing forcing result and it was changed in rust-lang#89978, I couldn't find any comments addressing this change. One way it can fail is by failing to recover the query in DepNodeParams::recover - when we are trying to query something that no longer exists in the current environment
Knowledge of
DepKinds is managed using two arrays containing flags (is_anon, eval_always, fingerprint_style), and function pointers (forcing and loading code).This PR aims at merging the two arrays so as to reduce unneeded indirect calls and (hopefully) increase code locality.
r? @ghost