-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Don't use mem::zeroed in vec::IntoIter #120952
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Don't use mem::zeroed in vec::IntoIter r? `@ghost`
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (218b423): comparison URL. Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeResultsThis 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.
Bootstrap: 664.283s -> 663.002s (-0.19%) |
35a9a09
to
78a4d71
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Don't use mem::zeroed in vec::IntoIter `mem::zeroed` is not a trivial function. Maybe it was once, but now it involves multiple locals, copies, and an intrinsic that gets monomorphized into a call to `panic_nounwind` for iterators of types like `Vec<&T>`. Of course all that complexity is trivially optimized out, but generating a bunch of IR where we don't need to just so we can optimize it away later is silly. r? `@ghost`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (0183a22): comparison URL. Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeResultsThis 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.
Bootstrap: 666.51s -> 663.607s (-0.44%) |
library/alloc/src/vec/into_iter.rs
Outdated
self.ptr = unsafe { old.add(1) }; | ||
|
||
Some(unsafe { ptr::read(old.as_ptr()) }) | ||
if self.ptr == unsafe { NonNull::new_unchecked(self.end as *mut T) } { |
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.
if the goal is IR reduction, well, NonNull::new_unchecked
does contain some assert_unsafe_precondition!
machinery too, the non_null!
macro avoids that.
78a4d71
to
eaa3133
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Don't use mem::zeroed in vec::IntoIter `mem::zeroed` is not a trivial function. Maybe it was once, but now it involves multiple locals, copies, and an intrinsic that gets monomorphized into a call to `panic_nounwind` for iterators of types like `Vec<&T>`. Of course all that complexity is trivially optimized out, but generating a bunch of IR where we don't need to just so we can optimize it away later is silly. r? `@ghost`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (491feef): comparison URL. Overall result: ❌ regressions - 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 a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeResultsThis 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.
Bootstrap: 664.301s -> 664.247s (-0.01%) |
The small binary size reduction in debug builds is the only real evidence that this PR is working as intended. So I'm happy to apply whatever cleanups in this module seem sensible, because I think tidying up the code is the primary outcome of this now. |
r? the8472 |
let new_end = unsafe { non_null!(self.end, T).sub(1) }; | ||
*non_null!(mut self.end, T) = new_end; | ||
|
||
Some(unsafe { ptr::read(new_end.as_ptr()) }) |
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.
next_back
isn't covered by codegen/vec-iter
. can you check if it still has the nonnull
attribute?
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.
While working on this, I think I realized that the transmute
strategy I was trying to adopt was working by sheer luck. I thought I was getting !nonnull
from the transmute range assumes, but we don't insert those for pointers. I'm looking into that, but not in this PR.
9c5a27f
to
83a9d95
Compare
☔ The latest upstream changes (presumably #120486) made this pull request unmergeable. Please resolve the merge conflicts. |
83a9d95
to
7c2db70
Compare
Don't use mem::zeroed in vec::IntoIter `mem::zeroed` is not a trivial function. Maybe it was once, but now it involves multiple locals, copies, and an intrinsic that gets monomorphized into a call to `panic_nounwind` for iterators of types like `Vec<&T>`. Of course all that complexity is trivially optimized out, but generating a bunch of IR where we don't need to just so we can optimize it away later is silly.
Don't use mem::zeroed in vec::IntoIter `mem::zeroed` is not a trivial function. Maybe it was once, but now it involves multiple locals, copies, and an intrinsic that gets monomorphized into a call to `panic_nounwind` for iterators of types like `Vec<&T>`. Of course all that complexity is trivially optimized out, but generating a bunch of IR where we don't need to just so we can optimize it away later is silly.
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#120952 (Don't use mem::zeroed in vec::IntoIter) - rust-lang#121079 (distribute tool documentations and avoid file conflicts on `x install`) - rust-lang#121085 (errors: only eagerly translate subdiagnostics) - rust-lang#121091 (use build.rustc config and skip-stage0-validation flag) - rust-lang#121193 (Use fulfillment in next trait solver coherence) - rust-lang#121209 (Make `CodegenBackend::join_codegen` infallible.) - rust-lang#121210 (Fix `cfg(target_abi = "sim")` on `i386-apple-ios`) - rust-lang#121228 (create stamp file for clippy) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#120952 (Don't use mem::zeroed in vec::IntoIter) - rust-lang#121085 (errors: only eagerly translate subdiagnostics) - rust-lang#121091 (use build.rustc config and skip-stage0-validation flag) - rust-lang#121149 (Fix typo in VecDeque::handle_capacity_increase() doc comment.) - rust-lang#121193 (Use fulfillment in next trait solver coherence) - rust-lang#121209 (Make `CodegenBackend::join_codegen` infallible.) - rust-lang#121210 (Fix `cfg(target_abi = "sim")` on `i386-apple-ios`) - rust-lang#121228 (create stamp file for clippy) - rust-lang#121231 (remove a couple of redundant clones) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#120952 - saethlin:vec-into-iter, r=the8472 Don't use mem::zeroed in vec::IntoIter `mem::zeroed` is not a trivial function. Maybe it was once, but now it involves multiple locals, copies, and an intrinsic that gets monomorphized into a call to `panic_nounwind` for iterators of types like `Vec<&T>`. Of course all that complexity is trivially optimized out, but generating a bunch of IR where we don't need to just so we can optimize it away later is silly.
mem::zeroed
is not a trivial function. Maybe it was once, but now it involves multiple locals, copies, and an intrinsic that gets monomorphized into a call topanic_nounwind
for iterators of types likeVec<&T>
. Of course all that complexity is trivially optimized out, but generating a bunch of IR where we don't need to just so we can optimize it away later is silly.