Try to improve into_slice_range inlining#157947
Conversation
|
@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.
Try to improve into_slice_range inlining
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (6a83d7f): comparison URL. Overall result: no relevant changes - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary 2.7%, secondary -2.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.4%, secondary -15.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 519.231s -> 519.196s (-0.01%) |
This is a possible solution to #157909. I think the root problem is that LLVM sees the many non-inlinable calls to
slice_index_failand decides that the function must be a bad inlining candidate.The other strategy I was thinking of was to call
try_into_slice_range. I think deduplicating the checking logic in the source between these two functions might just be a good cleanup. But first I'm going to check if this has unexpected perf impact, because I saw mentions ofRangeBoundsin the compiler source.