-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
transmute should also assume non-null pointers
#136735
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
Conversation
| // CHECK: %[[A:.+]] = load ptr | ||
| // CHECK-SAME: !nonnull | ||
| // CHECK: %[[B:.+]] = load ptr | ||
| // CHECK-SAME: !nonnull |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really not that substantial a difference, but saved a local and means it no longer has the pointer-to-pointer types.
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
`transmute` should also assume non-null pointers 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.
library/core/src/slice/iter.rs
Outdated
| /// [`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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that does sound better.
@rustbot author
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.
#[cfg_attr(not(doc), repr(C))] is also used in some places.
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.
Thanks, the test annotation worked to keep it passing.
@rustbot ready
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
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%) |
|
(syn is currently being noisy) |
|
Interesting, saved 630K off librustc_driver.so somehow, and a nice improvement in bootstrap time. |
48c0083 to
be1489f
Compare
Simplify `slice::Iter::next` enough that it inlines Inspired by this zulip conversation: <https://rust-lang.zulipchat.com/#narrow/channel/189540-t-compiler.2Fwg-mir-opt/topic/Feedback.20on.20a.20MIR.20optimization.20idea/near/498579990> Draft for now because it needs rust-lang#136735 to get the codegen tests to pass.
| } 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
|
Rebased to fix the conflict with the @bors r=oli-obk |
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
|
☀️ Test successful - checks-actions |
|
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%) |
|
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.