-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 all mono-time checks into their own folder, and their own query #132843
Conversation
@bors try |
This comment has been minimized.
This comment has been minimized.
move all mono-time checks into their own folder, and their own query The mono item collector currently also drives two mono-time checks: the lint for "large moves", and the check whether function calls are done with all the required target features. Instead of doing this "inside" the collector, this PR refactors things so that we have a new `rustc_monomorphize::mono_checks` module providing a per-instance query that does these checks. We already have a per-instance query for the ABI checks, so this should be "free" for incremental builds. Non-incremental builds might do a bit more work now since we now have two separate MIR visits (in the collector and the mono-time checks) -- but one of them is cached in case the MIR doesn't change so that seems nice? This slightly changes behavior of the large-move check since the "move_size_spans" deduplication logic now only works per-instance, not globally across the entire collector. We could save some work by sharing the visitor between the ABI checks and the move checks, but let's see perf before doing that work. Cc `@saethlin` since you're also doing some work related to queries and caching and monomorphization, though I don't know if there's any interaction here.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (0c32858): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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 may lead to changes in compiler perf. @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.2%, secondary 4.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 2.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 785.39s -> 786.581s (0.15%) |
That's not quite as much as I was hoping for given #132467, but even a neutral result is good news IMO since this cleans up the code. :) |
@bors try |
This comment has been minimized.
This comment has been minimized.
move all mono-time checks into their own folder, and their own query The mono item collector currently also drives two mono-time checks: the lint for "large moves", and the check whether function calls are done with all the required target features. Instead of doing this "inside" the collector, this PR refactors things so that we have a new `rustc_monomorphize::mono_checks` module providing a per-instance query that does these checks. We already have a per-instance query for the ABI checks, so this should be "free" for incremental builds. Non-incremental builds might do a bit more work now since we now have two separate MIR visits (in the collector and the mono-time checks) -- but one of them is cached in case the MIR doesn't change, which is nice. This slightly changes behavior of the large-move check since the "move_size_spans" deduplication logic now only works per-instance, not globally across the entire collector. Cc `@saethlin` since you're also doing some work related to queries and caching and monomorphization, though I don't know if there's any interaction here.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (562f46b): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking 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 may lead 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 Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.3%, secondary 1.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 2.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 787.115s -> 786.126s (-0.13%) |
That actually makes things worse? What the heck? I thought doing fewer Ah well, I'll un-do the 2nd commit then. |
f25b73b
to
23054c5
Compare
I don't think there is a significant difference between the two perf reports. The first one reports -0.21% on 3 primary benchmarks, and in the second, those results drop to -0.19%. Those are all incr-unchanged too. The Detailed Results for the single regression point to time in LLVM and the linker as the cause, which doesn't make any sense. I'd bet that benchmark is just unstable. |
Yeah, but my expectation was that this would help. Though, thinking about it more... it can only help when the query gets executed. The affected primary benchmarks are all incr-unchanged, so the query doesn't even get executed. The commit should have helped with full or incr-full builds, but I guess there the entire query is not a measurable part of the overall runtime. Keeping the visiting logic in the separate checks seems slightly cleaner to me (and avoids the |
} | ||
|
||
fn build_skip_move_check_fns(tcx: TyCtxt<'_>) -> Vec<DefId> { | ||
pub(crate) fn skip_move_check_fns(tcx: TyCtxt<'_>, _: ()) -> FxIndexSet<DefId> { |
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.
existing issue: but i feel like this should just be a diagnostics/rustc
attribute on these methods 😅 having a builtin list here is quite meh
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (583b25d): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 0.1%, secondary -4.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 784.209s -> 787.726s (0.45%) |
The mono item collector currently also drives two mono-time checks: the lint for "large moves", and the check whether function calls are done with all the required target features.
Instead of doing this "inside" the collector, this PR refactors things so that we have a new
rustc_monomorphize::mono_checks
module providing a per-instance query that does these checks. We already have a per-instance query for the ABI checks, so this should be "free" for incremental builds. Non-incremental builds might do a bit more work now since we now have two separate MIR visits (in the collector and the mono-time checks) -- but one of them is cached in case the MIR doesn't change, which is nice.This slightly changes behavior of the large-move check since the "move_size_spans" deduplication logic now only works per-instance, not globally across the entire collector.
Cc @saethlin since you're also doing some work related to queries and caching and monomorphization, though I don't know if there's any interaction here.