-
Notifications
You must be signed in to change notification settings - Fork 13.9k
[MIR] Store MIR in crate metadata #30301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
bcff7ba to
7786e1e
Compare
|
cc @alexcrichton @brson -- thoughts about binary size? this would only be temporary until MIR trans lands, of course, but that could be a little while. UPDATE: To be clear, I mean that eventually we would not have to include the HIR as well. |
|
r+ modulo the two comments -- no tests, but that's ok because this is going to be used very heavily and is already tested in mw's local branches (also, I don't believe there are any tests for metadata encoding-decoding at all, so no existing infrastructure) |
|
There've been some nice improvements to metadata size recently so this may just get us back to where we used to be at, so in that sense it's not that much worse. One possibility perhaps could be to only enable this on the nightly channel, but if MIR is enabled anywhere this seems ok to me as HIR is on its way out. |
|
So many bloat. We need to try and get it under control. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are you doing? Are we encoding non-erased regions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Region shows up in mir::repr::Rvalue so we need serialization implementations for it. At the encoding time it should always have been erased though.
7786e1e to
5addc31
Compare
At some point we definitely should, I agree. |
|
@bors r=nikomatsakis |
|
📌 Commit 5addc31 has been approved by |
This PR makes `Mir` `RustcEncodable` and `RustcDecodable` and stores it in crate metadata for inlinable items. Some other things in here: - `mir::visit::Visitor` is extended to also visit `Literals`, `Spans` and `DefIds`. - It also adds `mir::visit::MutVisitor` which allows to mutate the visited `Mir` structure in place. - Some numbers on how big MIR is in metadata (total metadata size in bytes): | | w/ MIR | w/o MIR | Rel. Size | |----------------|-----------:|------------:|:---------:| | libcore | 17,695,473 | 14,263,377 | 124% | | liblibc | 411,440 | 404,382 | 102% | | libcollections | 4,537,975 | 3,526,933 | 129% | | libserialize | 2,574,769 | 2,060,798 | 125% | | libsyntax | 15,262,894 | 12,075,574 | 126% | | librustc | 16,984,537 | 13,692,168 | 124% | So, adding MIR to metadata makes it about 25% bigger. It could be worse, considering that it still uses the inefficient RBML encoding. Still, the question is whether we should put MIR emission behind a `-Z` flag.
This PR makes
MirRustcEncodableandRustcDecodableand stores it in crate metadata for inlinable items.Some other things in here:
mir::visit::Visitoris extended to also visitLiterals,SpansandDefIds.mir::visit::MutVisitorwhich allows to mutate the visitedMirstructure in place.So, adding MIR to metadata makes it about 25% bigger. It could be worse, considering that it still uses the inefficient RBML encoding. Still, the question is whether we should put MIR emission behind a
-Zflag.