-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
[EXPERIMENT] Don't monomorphize things that are unused due to if <T as Trait>::CONST
#91222
Conversation
MIR optimizations have long meant that we do this for concrete constants, but with this it also applies for things like `<T as TrustedRandomAccess>::MAY_HAVE_SIDE_EFFECT`.
Queue's empty, so... @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 568fe20 with merge 258c6a0d164d6864d65295e968956d4cc6e246f2... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
The following could be a juicier one if it were extracted to an associated const if that works together with specialization rust/library/alloc/src/vec/source_iter_marker.rs Lines 24 to 28 in 862962b
I can prepare a PR for that if it helps. |
Hmm, interesting that the -- @the8472 If you're excited to I'd happily take it in the branch, but this is still experimental enough that I can't honestly say that you should. It's still perfectly likely that this will go nowhere, so I wouldn't want you to waste time. Honestly this PR might not be worth it until inline consts work so that could just be if const {
mem::size_of::<T>() == 0
|| mem::size_of::<T>()
!= mem::size_of::<<<I as SourceIter>::Source as AsIntoIter>::Item>()
|| mem::align_of::<T>()
!= mem::align_of::<<<I as SourceIter>::Source as AsIntoIter>::Item>()
} {
// fallback to more generic implementations
return SpecFromIterNested::from_iter(iterator);
} instead, and not need a whole bunch of these little one-use traits. But right now they're using the basic "sugar for (The context for this PR was seeing if I could get #85836 working.) |
associated const PR over at scottmcm#3 |
extract const guard to trait associated const for optimization experiment
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b728f16603191d29dda030521911a25c2e328c8d with merge 813a1d70587279815e909f5fc757d2e02322392e... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
Queued 813a1d70587279815e909f5fc757d2e02322392e with parent 9adfd9d, future comparison URL. |
Finished benchmarking commit (813a1d70587279815e909f5fc757d2e02322392e): comparison url. Summary: This change led to large 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 |
And hey, maybe even be faster because it means less IR emitted.
b728f16
to
b5d6de2
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
Tweak inlining attributes for slice indexing Doing some experiments in response to this unexpected regression: rust-lang#120863 (comment) I expect the opt changes to be addressed by something like reviving rust-lang#91222. The debug changes are what I'm interested in. Codegen tests will probably fail from time to time in this PR, I will fix them up later but also I don't trust the opt-level-z one: rust-lang#119878 (comment) r? `@ghost`
Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848
Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848
Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848
Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848
Avoid lowering code under dead SwitchInt targets The objective of this PR is to detect and eliminate code which is guarded by an `if false`, even if that `false` is a constant which is not known until monomorphization, or is `intrinsics::debug_assertions()`. The effect of this is that we generate no LLVM IR the standard library's unsafe preconditions, when they are compiled in a build where they should be immediately optimized out. This mono-time optimization ensures that builds which disable debug assertions do not grow a linkage requirement against `core`, which compiler-builtins currently needs: rust-lang#121552 This revives the codegen side of rust-lang#91222 as planned in rust-lang#120848.
Avoid lowering code under dead SwitchInt targets The objective of this PR is to detect and eliminate code which is guarded by an `if false`, even if that `false` is a constant which is not known until monomorphization, or is `intrinsics::debug_assertions()`. The effect of this is that we generate no LLVM IR the standard library's unsafe preconditions, when they are compiled in a build where they should be immediately optimized out. This mono-time optimization ensures that builds which disable debug assertions do not grow a linkage requirement against `core`, which compiler-builtins currently needs: rust-lang#121552 This revives the codegen side of rust-lang#91222 as planned in rust-lang#120848.
Fixes #85836
MIR optimizations have long meant that we do this for concrete constants, but with this change it also applies for things like
<T as TrustedRandomAccess>::MAY_HAVE_SIDE_EFFECT
.There's likely not enough of this stuff for the extra work to be worth it, but I'm curious to see anyway.
r? @ghost