-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Move encode_metadata out of CrateStore. #89183
Conversation
Some changes occured to rustc_codegen_cranelift cc @bjorn3 |
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
Can you move EncodedMetadata to rustc_metadata? |
@bors try @rust-timer queue Calls through a trait object might be saving us some codegen time and such (if things are not getting inlined, etc.). Seems unlikely, but worth checking, I think. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 53cd5168934f0567537415e54fe9d36aa86089bd with merge bb92ee19d26561c6b263a4c79e77c0b2dc084980... |
☀️ Try build successful - checks-actions |
Queued bb92ee19d26561c6b263a4c79e77c0b2dc084980 with parent 308dffd, future comparison URL. |
Finished benchmarking commit (bb92ee19d26561c6b263a4c79e77c0b2dc084980): comparison url. Summary: This change led to small relevant regressions 😿 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 |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #89092) made this pull request unmergeable. Please resolve the merge conflicts. |
the change lgtm, but considering it's just a redesign, but regresses perf, should we really do this? Do you need this for some other PRs? |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit c013cd38c94f26e9fd03b73db411530d87ad2dff with merge afea9a948dbff21b30109ada462b7bda076ac676... |
☀️ Try build successful - checks-actions |
Queued afea9a948dbff21b30109ada462b7bda076ac676 with parent 8f8092c, future comparison URL. |
Finished benchmarking commit (afea9a948dbff21b30109ada462b7bda076ac676): 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 |
@bors r+ |
📌 Commit 2d51b78 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1c0ed0d): 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. @rustbot label: -perf-regression |
Move ICH to rustc_query_system Based on rust-lang#89183 The StableHashingContext does not need to be in rustc_middle. This PR moves it to rustc_query_system. This will avoid a dependency between rustc_ast_lowering and rustc_middle in rust-lang#89124.
rustc_metadata
is already accessible by all client crates. It does not need to be called trough a trait object.