-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Optimize indexing slices and strs with inclusive ranges #145024
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
base: main
Are you sure you want to change the base?
Conversation
|
r? @ibraheemdev rustbot has assigned @ibraheemdev. Use |
This comment has been minimized.
This comment has been minimized.
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.
As you saw from the PR build failure, if you're touching things like slice_index_order_fail you'll need to look through every mention of those in the repo -- there are a bunch of codegen tests that look for their absence, and you need to make sure that you don't make those tests useless by renaming what they're looking for.
(You probably also need to re-bless some MIR tests that include indexing.)
eab010d to
61bcd82
Compare
This comment has been minimized.
This comment has been minimized.
61bcd82 to
2546221
Compare
This comment has been minimized.
This comment has been minimized.
2546221 to
a61fde0
Compare
|
The Miri subtree was changed cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
48b325f to
87a3889
Compare
This comment has been minimized.
This comment has been minimized.
87a3889 to
bd63d02
Compare
This comment has been minimized.
This comment has been minimized.
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Optimize indexing slices and strs with inclusive ranges
bd63d02 to
194cfc3
Compare
|
@scottmcm ping? |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Optimize indexing slices and strs with inclusive ranges
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (ddd9a12): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (primary 9.4%, secondary 5.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 472.506s -> 472.489s (-0.00%) |
This comment has been minimized.
This comment has been minimized.
Add a `codegen-llvm` test to check the number of `icmp` instrucitons generated for each `SliceIndex` method on the various range types. This will be updated in the next commit when `SliceIndex::get` is optimized for `RangeInclusive`.
This comment was marked as resolved.
This comment was marked as resolved.
| } | ||
|
|
||
| // CHECK-LABEL: @get_range | ||
| // CHECK-COUNT-9: %{{.+}} = icmp |
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.
Are you sure this is a useful test? The string code is comparatively complex and some of these are for the char boundaries and some of it is for slices, etc. Maybe at least worth annotating with why there's this number?
|
Reminder, once the PR becomes ready for a review, use |
ab33748 to
0f259ac
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
The check for `self.end() == usize::MAX` can be combined with the `self.end() + 1 > slice.len()` check into `self.end() >= slice.len()`, since `self.end() < slice.len()` implies both `self.end() <= slice.len()` and `self.end() < usize::MAX`.
Same reasoning as previous two commits.
The panic message when slicing a string with a negative length range (eg `"abcdef"[4..3]`) is confusing: it gives the condition that failed to hold, whilst all the other panic messages give the condition that did hold. Before: begin <= end (4 <= 3) when slicing `abcdef` After: begin > end (4 > 3) when slicing `abcdef`
Rename `into_range` to `try_into_slice_range`: - Prepend `try_` to show that it returns `None` on error, like `try_range` - add `_slice` to make it consistent with `into_slice_range`
0f259ac to
0b26613
Compare
Instead of separately checking for
end == usize::MAXandend + 1 > slice.len(), we can check forend >= slice.len(). Also consolidate all the slice indexing related panic functions into a single function which reports the correct error depending on the arguments, as the str indexing code already does.The downside of all this is that the panic message is slightly less specific when trying to index with
[..=usize::MAX]: instead of saying "attempted to index slice up to maximum usize" it just says "range end index {end} out of range for slice of length {len}". But this is a rare enough case that I think it is acceptable