Validate miri against the HIR const evaluator #45002
Conversation
make force_allocation handle packed ByValPair
fix for latest nightly
previously miri had a check for const fn and other cases that CTFE requires. Instead the function call is completely processed inside the machine. This allows CTFE to have full control over what is called and miri to not have useless CTFE-checks in normal mode.
Split up miri into the librustc_mir and bin parts
Process untagged unions
|
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. |
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. |
soo... uhm... I've been looking at the wrong thing the entire time |
|
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? |
src/bootstrap/builder.rs
Outdated
| @@ -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()) | |||
There was a problem hiding this comment.
found the issue (I think)
Specifically checking the size increase of RLS:
Comparing the sections with `llvm-readelf -sections rls-preview/bin/rls`:
It's definitely the debug symbols. All the extra size is occupied by debug symbols. |
|
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... |
|
📌 Commit 7a2bff7 has been approved by |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit 7a2bff7 has been approved by |
kennytm
added
S-waiting-on-bors
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit 7a2bff7 has been approved by |
Validate miri against the HIR const evaluator r? @eddyb cc @alexcrichton @arielb1 @RalfJung The interesting parts are the last few functions in `librustc_const_eval/eval.rs` * We warn if miri produces an error while HIR const eval does not. * We warn if miri produces a value that does not match the value produced by HIR const eval * if miri succeeds and HIR const eval fails, nothing is emitted, but we still return the HIR error * if both error, nothing is emitted and the HIR const eval error is returned So there are no actual changes, except that miri is forced to produce the same values as the old const eval. * This does **not** touch the const evaluator in trans at all. That will come in a future PR. * This does **not** cause any code to compile that didn't compile before. That will also come in the future It would be great if someone could start a crater run if travis passes
|
☀️ Test successful - status-appveyor, status-travis |
|
I don't remember... sorry |
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