[experimental] Perform cross-lang-lto for librustc_codegen_llvm. #53855
Conversation
This file contains 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
|
(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
Aug 31, 2018
[experimental] Perform cross-lang-lto for librustc_codegen_llvm. This is a follow-up to #53245 in order to gauge the impact of cross-language LTO on `rustc`.
|
Oh, I just remembered: This probably won't work because CI uses Clang 6.0 but cross-language LTO needs Clang 7. Otherwise the LLVM versions of Clang and Rust are not compatible. |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-author
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Heh and sure enough! |
|
LLVM 7 is due on Sep 5, I'll mark as blocked until then. |
michaelwoerister
added
the
S-blocked
|
Hm, now that |
|
I tried this out locally, building LLVM with current Clang master and then running the perf.rlo test suite and the results look like there's pretty much no performance win at all: I verified that things are actually inlined cross-language by picking a few (5-6) small functions from 92029: 1412d69: e8 42 d1 2e 02 callq 36ffeb0 <LLVMGetIntTypeWidth@plt>in the Rust code, while for the cross-lang version, no calls could be found, just the definition: 00000000033668e0 <LLVMGetIntTypeWidth>:
33668e0: 8b 47 08 mov 0x8(%rdi),%eax
33668e3: c1 e8 08 shr $0x8,%eax
33668e6: c3 retq
33668e7: cc int3
33668e8: cc int3
33668e9: cc int3
33668ea: cc int3
33668eb: cc int3
33668ec: cc int3
33668ed: cc int3
33668ee: cc int3
33668ef: cc int3 Every function I looked at was actually inlined, so the optimization works as expected. It seems to have little effect on runtime performance though, at least for the compiler's codegen backend. If someone wants to verify these results independently, here are the respective branches:
These branches have their cc @rust-lang/compiler @rust-lang/wg-compiler-performance @rust-lang/wg-codegen |
|
@michaelwoerister I wouldn’t expect much change in compile time by optimising LIR->LLVM-IR translation – it already takes a very small part of compilation time, so even removing that part will not affect time final timings much. Nice to see xLTO working though! |
|
I'm closing this since it would require quite a bit of work on the CI side and (at least in my local test run) does not provide any substantial gains in performance. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
This is a follow-up to #53245 in order to gauge the impact of cross-language LTO on
rustc.