rustc(codegen): uncache def_symbol_name prefix from symbol_name.
#59343
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors try |
bors
added a commit
that referenced
this pull request
Mar 21, 2019
rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`. The `def_symbol_name` query was an optimization to avoid recomputing the common part of a symbol name, as only the hash needs to be added to it for each symbol. However, #57967 will add a new mangling scheme, which doesn't readily support this kind of reuse - while it's plausible, it requires a lot more effort, since you'd have to "symbolically evaluate" mangling, and keep it in a form where the backreference positions can be computed correctly in the final step. So I want to see how much time we're actually saving with this `def_symbol_name` optimization, nowadays.
|
☀️ Try build successful - checks-travis |
|
@rust-timer build 7172250 |
|
Success: Queued 7172250 with parent 48e354d, comparison URL. |
|
Finished benchmarking try commit 7172250 |
|
Perf is randomly better or worse, but all below 1%. Max-rss seems to mostly have improvements, but that might just be noise, I don't know what the usual variances are. impl lgtm |
|
📌 Commit 3590a46 has been approved by |
bors
added
S-waiting-on-bors
|
☔ The latest upstream changes (presumably #59433) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
added
S-waiting-on-author
eddyb
force-pushed
the
rm-def-symbol-name
branch
from
3590a46 to
03639a2
Compare
|
@bors r=michaelwoerister |
|
📌 Commit 03639a2 has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Mar 30, 2019
…woerister rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`. The `def_symbol_name` query was an optimization to avoid recomputing the common part of a symbol name, as only the hash needs to be added to it for each symbol. However, rust-lang#57967 will add a new mangling scheme, which doesn't readily support this kind of reuse - while it's plausible, it requires a lot more effort, since you'd have to "symbolically evaluate" mangling, and keep it in a form where the backreference positions can be computed correctly in the final step. So I want to see how much time we're actually saving with this `def_symbol_name` optimization, nowadays. cc @michaelwoerister
bors
added a commit
that referenced
this pull request
Mar 30, 2019
Rollup of 5 pull requests Successful merges: - #59343 (rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`.) - #59380 (Fix invalid DWARF for enums when using ThinLTO) - #59463 (skip dyn keyword lint under macros) - #59539 (Fix infinite recursion) - #59544 (manifest: only include miri on the nightly channel) Failed merges: r? @ghost
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
def_symbol_namequery was an optimization to avoid recomputing the common part of a symbol name, as only the hash needs to be added to it for each symbol.However, #57967 will add a new mangling scheme, which doesn't readily support this kind of reuse - while it's plausible, it requires a lot more effort, since you'd have to "symbolically evaluate" mangling, and keep it in a form where the backreference positions can be computed correctly in the final step.
So I want to see how much time we're actually saving with this
def_symbol_nameoptimization, nowadays.cc @michaelwoerister