Inline read_{un,}signed_leb128 and opaque::Decoder functions. #37083
Conversation
|
r? @erickt (rust_highfive has picked a reviewer for you, use r? to override) |
|
Leaving a comment on these methods noting why this was done is probably a good idea so a future clean-up doesn't accidentally remove this optimization, since it's not intuitively a good idea to maintain a pointer to a usize instead of copying it back and forth. |
|
FWIW, I'm treating @Mark-Simulacrum's comment as a suggestion worth considering, but I'm still waiting for @erickt to review before I make any changes. |
|
@nnethercote: Looks good to me if you add the comment. This seems a tad magical though. I would have expected llvm to generate similar code. Maybe it's having trouble doing return-value optimization? I wonder if this is an area a MIR optimization could target. |
|
@erickt It's because the function is not marked as |
I've added that, and also inlined all the methods within |
These functions are all hot in rustc and inlining them speeds up most of the rustc-benchmarks by 1--2%.
|
stage1: |
nnethercote
changed the title
|
@bors r+ |
|
📌 Commit 6a4bb35 has been approved by |
Inline read_{un,}signed_leb128 and opaque::Decoder functions.
`read_unsigned_leb128` is hot within rustc because it's heavily used
during the reading of crate metadata. This commit tweaks its signature
(and that of `read_signed_leb128`, for consistency) so it can increment
the buffer index directly instead of maintaining its own copy, the
change in which is then used by the caller to advance the index.
This reduces the instruction count (as measured by Cachegrind) for some
benchmarks a bit, e.g. hyper-0.5.0 by 0.7%.
brson
added
the
relnotes
read_unsigned_leb128is hot within rustc because it's heavily usedduring the reading of crate metadata. This commit tweaks its signature
(and that of
read_signed_leb128, for consistency) so it can incrementthe buffer index directly instead of maintaining its own copy, the
change in which is then used by the caller to advance the index.
This reduces the instruction count (as measured by Cachegrind) for some
benchmarks a bit, e.g. hyper-0.5.0 by 0.7%.