transmute should also assume non-null pointers - #136735
Conversation
commented
Feb 8, 2025
| // CHECK: %[[A:.+]] = load ptr | ||
| // CHECK-SAME: !nonnull | ||
| // CHECK: %[[B:.+]] = load ptr | ||
| // CHECK-SAME: !nonnull |
There was a problem hiding this comment.
annot: this now goes through the transmute instead of the load-as-nonnull, but still ends up getting the !nonnull on the load as desired. (And all the https://github.com/rust-lang/rust/blob/master/tests/codegen/slice-iter-nonnull.rs tests still pass as well, no updates needed.)
This comment has been minimized.
This comment has been minimized.
486645f to
48c0083
Compare
| let mut _2: *const *const T; | ||
| let mut _3: *const std::ptr::NonNull<T>; | ||
| let mut _8: *const T; | ||
| let mut _2: *const T; | ||
| let mut _7: *const T; |
There was a problem hiding this comment.
Really not that substantial a difference, but saved a local and means it no longer has the pointer-to-pointer types.
commented
Feb 8, 2025
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
commented
Feb 8, 2025
| /// [`iter_mut`]: slice::iter_mut | ||
| /// [slices]: slice | ||
| #[stable(feature = "rust1", since = "1.0.0")] | ||
| #[repr(C)] // *Not* a guarantee, but keeps the codegen tests consistent |
There was a problem hiding this comment.
Is this about layout randomization? If so then using the //@ needs-deterministic-layouts test annotation should be better, that way people can still get randomized iters.
There was a problem hiding this comment.
#[cfg_attr(not(doc), repr(C))] is also used in some places.
There was a problem hiding this comment.
Thanks, the test annotation worked to keep it passing.
@rustbot ready
commented
Feb 8, 2025
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
commented
Feb 8, 2025
|
Finished benchmarking commit (6ae82df): 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 -0.4%, 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.
CyclesResults (primary 0.9%, secondary 2.8%)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 sizeResults (primary -0.2%, secondary -0.0%)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.
Bootstrap: 781.002s -> 777.406s (-0.46%) |
commented
Feb 8, 2025
|
(syn is currently being noisy) |
commented
Feb 9, 2025
|
Interesting, saved 630K off librustc_driver.so somehow, and a nice improvement in bootstrap time. |
48c0083 to
be1489f
Compare
| } else { | ||
| // SAFETY: for non-ZSTs, the type invariant ensures it cannot be null | ||
| let $end = unsafe { *(&raw const $this.end_or_len).cast::<NonNull<T>>() }; | ||
| let $end = unsafe { mem::transmute::<*const T, NonNull<T>>($this.end_or_len) }; |
There was a problem hiding this comment.
Would it make sense/work to use NonNull::new_unchecked here and make the body of that use a transmute instead?
There was a problem hiding this comment.
In general I would like to move NonNull to using transmutes.
But in this specific case I really don't want to do that, because it adds a UbCheck which would then have major impact on perf because of just how critical next is.
(Though maybe after #136771, once the super-critical methods aren't using this helper macro any more, it could be worth trying.)
be1489f to
083672b
Compare
commented
Feb 13, 2025
|
Rebased to fix the conflict with the @bors r=oli-obk |
commented
Feb 13, 2025
This comment has been minimized.
This comment has been minimized.
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
083672b to
0cc14b6
Compare
commented
Feb 13, 2025
commented
Feb 14, 2025
commented
Feb 14, 2025
|
☀️ Test successful - checks-actions |
commented
Feb 14, 2025
|
Finished benchmarking commit (d88ffcd): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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.5%, secondary -0.0%)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 (primary -1.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 sizeResults (primary -0.2%, secondary -0.0%)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.
Bootstrap: 787.772s -> 789.359s (0.20%) |
commented
Feb 18, 2025
|
Performance is a wash. @rustbot label: +perf-regression-triaged |
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.