-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rearrange slice::split_mut to remove bounds check #99223
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
(rust-highfive has picked a reviewer for you, use r? to override) |
If you feel up to writing a codegen test, I'm all for codegen tests in general. But I don't feel it's necessary here. |
d60ed7d
to
82cb5d8
Compare
82cb5d8
to
c937390
Compare
@rustbot ready |
I am choosing the lazy route with no codegen test, because as mentioned I have convinced myself that this pattern is strictly easier to optimize. |
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9ed0bf9): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
rust-lang/rust#99223 fixes the bounds check in split_mut and splitn_mut, so no need to carry those custom implementations anymore. Also tweak some of the bounds checking code in the target.xml handler, since it re-introduced a bounds check in newer rustc versions...
Closes #86313
Turns out that all we need to do here is reorder the bounds checks to convince LLVM that all the bounds checks can be removed. It seems like LLVM just fails to propagate the original length information past the first bounds check and into the second one. With this implementation it doesn't need to, each check can be proven inbounds based on the one immediately previous.
I've gradually convinced myself that this implementation is unambiguously better based on the above logic, but maybe this is still deserving of a codegen test?
Also the mentioned borrowck limitation no longer seems to exist.