Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upValidate miri against the HIR const evaluator #45002
Conversation
oli-obk
and others
added some commits
Jul 31, 2017
bors
added a commit
that referenced
this pull request
Dec 14, 2017
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
Nevermind, looked at the DEPLOY_ALT builder. The DEPLOY builder decreased further in size |
This comment has been minimized.
This comment has been minimized.
|
At this point I don't know where the increase in size is coming from. Miri is adding nothing measurable to librustc and like 2MB to librustc_mir. I don't see how the other crates' size increases can come from miri. It's a 23MB increase, which still is 12%. All I can think of now is that it severly degraded the zippability of the crates, because the unzipped crates seem to not have increased by that much. |
This comment has been minimized.
This comment has been minimized.
Since the tarballs are actually uploaded we could download them and check locally.
It doesn't look like related to zippability, but an actual increase in binary size. Edit: Comparing top largest files in the tarball (sorted by "after"):
Why did RLS and Cargo becomes so much larger? They contribute almost all of the size increase. |
This comment has been minimized.
This comment has been minimized.
soo... uhm... I've been looking at the wrong thing the entire time |
This comment has been minimized.
This comment has been minimized.
|
Did we change the situations in which we generate MIR for libraries, or the MIR itself? Are we compiling some new dependencies as rlibs and thus duplicating them in the binaries somehow? |
oli-obk
reviewed
Dec 14, 2017
| @@ -495,13 +495,11 @@ impl<'a> Builder<'a> { | |||
| if let Some(target_linker) = self.build.linker(target) { | |||
| cargo.env("RUSTC_TARGET_LINKER", target_linker); | |||
| } | |||
| cargo.env("RUSTC_DEBUGINFO", self.config.rust_debuginfo.to_string()) | |||
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
While it's not fun to debug the tools without debug info, I can just activate it when needed. (confirmed locally that the binary size of the tools is back to what it's supposed to be) Launching miri 3... |
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
|
|
kennytm
added
S-waiting-on-bors
and removed
S-waiting-on-author
labels
Dec 14, 2017
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
bors
added a commit
that referenced
this pull request
Dec 14, 2017
This comment has been minimized.
This comment has been minimized.
|
|

oli-obk commentedOct 3, 2017
•
edited
r? @eddyb
cc @alexcrichton @arielb1 @RalfJung
The interesting parts are the last few functions in
librustc_const_eval/eval.rsSo there are no actual changes, except that miri is forced to produce the same values as the old const eval.
It would be great if someone could start a crater run if travis passes