Uh oh!
There was an error while loading. Please reload this page.
Allow for re-using monomorphizations in upstream crates. - #48779
Conversation
rust-highfive
commented
Mar 6, 2018
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
michaelwoerister
commented
Mar 6, 2018
@bors try |
bors
commented
Mar 6, 2018
⌛ Trying commit 35c9b1f2f0a365187789fc684cdb5eba9afb81dd with merge 55221f5e2d6d5c71f6b89674eb29f2a213f415ef... |
bors
commented
Mar 6, 2018
☀️ Test successful - status-travis |
michaelwoerister
commented
Mar 6, 2018
@Mark-Simulacrum, could you do a perf run for this too, please? |
Mark-Simulacrum
commented
Mar 7, 2018
Perf queued. Probably about 40-45 minutes until it starts. |
michaelwoerister
commented
Mar 7, 2018
Thanks, @Mark-Simulacrum! Here's the link: |
michaelwoerister
commented
Mar 7, 2018
@Mark-Simulacrum, the results don't seem to be available yet. Is it still in the queue or has something gone wrong? |
9a1af56 to
710e4d6CompareMark-Simulacrum
commented
Mar 7, 2018
Hm, it does look like something went wrong -- I've restarted the build. |
michaelwoerister
commented
Mar 7, 2018
Will the link be the same? |
Mark-Simulacrum
commented
Mar 7, 2018
Hm, it failed again -- I'm going to try and keep an eye on it and hopefully diagnose why, it also turns out we weren't properly logging the failures for try builds previously so I've now corrected that as well. |
Mark-Simulacrum
commented
Mar 7, 2018
URL works now! |
michaelwoerister
commented
Mar 8, 2018
Thanks, Mark! |
michaelwoerister
commented
Mar 8, 2018
OK, so those numbers look good. I had hoped that they would be even better though. It looks like it's mostly small functions that get re-used. But yeah, -15.9% for tokio-web-push, I'll take it |
michaelwoerister
commented
Mar 8, 2018
@rust-lang/compiler & @alexcrichton, do you have any objections to pursuing this further? There's a description at the top and performance numbers are here: http://perf.rust-lang.org/compare.html?start=6f2100b92cb14fbea2102701af6a3ac5814bd06c&end=55221f5e2d6d5c71f6b89674eb29f2a213f415ef&stat=instructions%3Au |
alexcrichton
commented
Mar 8, 2018
Awesome work here @michaelwoerister! It's pretty neat how it's not to difficult to play around with various schemes like this these days :) One concern I might have here is the size of binaries but given that this only affects debug mode rather than optimized then I guess it doesn't matter too much? We rely on In general though seems like a great idea to me to keep pursuing, any bugs or surprises along the way we can probably smooth over! For the diamond problem you gisted above, is this what all that "link once ODR" stuff is for in LLVM? I feel like that's all basically intended for optimized binaries linking only one copy rather than for debug mode, so it may not benefit us much if we don't turn this on in optimized mode. Speaking of optimized mode though, we may actually be able to get some nice wins here with |
michaelwoerister
commented
Mar 8, 2018
The monomorphizations are still assigned We could look into |
michaelwoerister
commented
Mar 8, 2018
Also, thanks for the feedback, @alexcrichton! |
alexcrichton
commented
Mar 8, 2018
Oh right that's true, I'd sort of doubt that I think that for executables we don't currently pass linker scripts/symbol whitelists, but AFAIK that's because we just never have before. We could likely start now! |
michaelwoerister
commented
Mar 8, 2018
OK, I'll make sure we do as part of the PR. |
nikomatsakis
commented
Mar 8, 2018
We discussed this in the @rust-lang/compiler meeting today. Everybody felt pretty good about it. It'd be nice to land this and possibly do further experimentation to see if we can enable in optimized builds without hurting perf. |
be1e8f6 to
d4264dcComparebors
commented
Apr 5, 2018
💔 Test failed - status-travis |
TimNN
commented
Apr 5, 2018
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. 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 |
1 similar comment
TimNN
commented
Apr 5, 2018
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. 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 |
…upport Rust dylibs.
michaelwoerister
commented
Apr 6, 2018
@bors r=alexcrichton |
bors
commented
Apr 6, 2018
📌 Commit 61991a5 has been approved by |
bors
commented
Apr 6, 2018
bors
commented
Apr 6, 2018
☀️ Test successful - status-appveyor, status-travis |
| pub const TAG_INVALID_SPAN: u8 = 1; | ||
| #[derive(RustcEncodable, RustcDecodable)] | ||
| pub struct EncodedExportedSymbols { |
There was a problem hiding this comment.
This should have a comment on it, that it's used to avoid adding a 'tcx parameter to CrateRoot (which I'm not even sure is a problem, if covariant, we'd just store it as 'static).
Followup to #48611. This implementation is pretty much finished modulo failing tests if there are any. Not quite ready for review yet though.
DESCRIPTION
This PR introduces a
share-genericsmode for RLIBs and Rust dylibs. When a crate is compiled in this mode, two things will happen:This results in less code being translated and LLVMed. However, there are also downsides:
Consequently, this PR only enables the
shared-genericsmode for opt-levelsNo,Less,Size, andMinSize, and for when incremental compilation is activated.-O2and-O3will still generate generic functions per-crate.Another thing to note is that this has a somewhat similar effect as MIR-only RLIBs, in that monomorphizations are shared, but it is less effective because it cannot share monomorphizations between sibling crates:
With
share-generics, bothBandChave to instantiatefoo<u32>and onlyDcan re-use it (from eitherBorC). With MIR-only RLIBs,BandCwould not instantiate anything, and inDwe would then only instantiatefoo<u32>once.On the other hand, when there are many leaf crates in the graph (e.g. when compiling many individual test binaries) then the
share-genericsapproach will often be more effective.TODO