Closed bjorn3 closed 3 years ago
The problem is UnOp::Neg
not being implemented for i128.
thread 'main' panicked at 'not yet implemented', /Users/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/c2-chacha-0.2.2/src/guts.rs:260:1
Filled https://github.com/cryptocorrosion/cryptocorrosion/issues/25 for running without SIMD.
Pushed 6129921529e2b4787a0d206244c7a858622b8d6d with some fixes necessary for this.
libcore
compiled by patching c2-chacha
to not passthrough the simd
feature to ppv-lite86
.
Now there are two const_err's which don't make sense:
[...]
error: any use of this value will cause an error
--> src/liballoc/raw_vec.rs:145:18
|
127 | pub const NEW: Self = Self::new();
| ----------------------------------
...
145 | cap: [0, !0][(mem::size_of::<T>() == 0) as usize],
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| index out of bounds: the len is 2 but the index is 0
| inside call to `raw_vec::RawVec::<u8>::new` at src/liballoc/raw_vec.rs:127:27
|
= note: `#[deny(const_err)]` on by default
fatal runtime error: failed to initiate panic, error 5
error: could not compile `alloc`.
Caused by:
process didn't exit successfully: `/Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/bootstrap/debug/rustc --edition=2018 --crate-name alloc src/liballoc/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C debuginfo=0 --cfg 'feature="compiler-builtins-c"' -C metadata=597966ce1b444f59 -C extra-filename=-597966ce1b444f59 --out-dir /Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps --target x86_64-apple-darwin -L dependency=/Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps -L dependency=/Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/x86_64-apple-darwin/stage1-std/release/deps --extern compiler_builtins=/Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps/libcompiler_builtins-259284571ab1a5fb.rmeta --extern core=/Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps/libcore-7f5c6d7d2df26804.rmeta -Zexternal-macro-backtrace -Zosx-rpath-install-name '-Clink-args=-Wl,-rpath,@loader_path/../lib' -Wrust_2018_idioms -Wunused_lifetimes -Cprefer-dynamic -Zbinary-dep-depinfo -L native=/Users/bjorn/Documents/rustc_codegen_cranelift/rust/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/build/compiler_builtins-f2fb94987d72e611/out` (signal: 6, SIGABRT: process abort signal)
warning: build failed, waiting for other jobs to finish...
error: this expression will panic at runtime
--> src/libpanic_unwind/gcc.rs:156:25
|
156 | if actions as i32 & uw::_UA_SEARCH_PHASE as i32 != 0 {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to add with overflow
|
= note: `#[deny(const_err)]` on by default
fatal runtime error: failed to initiate panic, error 5
error: could not compile `panic_unwind`.
[...]
Marked as bug because of the impossible const_err
's.
I got rustc bootstrapping using cg_clif. Unfortunately the rustc built using cg_clif crashes when you try to use it. So far I have been able to pin point that make_input
returns an io::Error
. When trying to .to_string()
it it turns out that the io::Error
has an invalid discriminant.
Rust fork: https://github.com/bjorn3/rust/commit/e5c309197bf97c12c5d0782b9300417a52c80f66 (branch cg_clif_subtree)
cg_clif commit: https://github.com/bjorn3/rustc_codegen_cranelift/commit/f7eb36070c602f0dccca26ccec83f1c003cb27dd (branch wip_proc_macro_fixes, clone it to src/rustc_codegen_cranelift
in the rust source repo)
Cranelift commit: https://github.com/bjorn3/wasmtime/commit/2d60da466dc375b0cb08ad62e49879927f176619 (pr bytecodealliance/wasmtime#1559, clone it to the parent dir of the rust repo, or edit Cargo.toml of the rust repo to point to it in the patch section)
config.toml:
[rust]
codegen-backends = ["cranelift"]
deny-warnings = false
Rust fork: https://github.com/bjorn3/rust/commit/42728c0730229daad922372f76e08f5e40c31aa1 cg_clif commit: https://github.com/bjorn3/rustc_codegen_cranelift/commit/4a48a39b45a0a90974f36790137ab16dc949026b Cranelift commit: https://github.com/bjorn3/wasmtime/commit/abe03816a034b261f4bd199500e4d4bb38ff4b2f (pr bytecodealliance/wasmtime#1559, clone it to the parent dir of the rust repo, or edit Cargo.toml of the rust repo to point to it in the patch section)
Edit has_cpuid
in corearch
to always return false.
config.toml:
[build]
full-bootstrap = true
[rust]
codegen-backends = ["cranelift"]
deny-warnings = false
Current failure:
The ICE happens at https://github.com/bjorn3/rust/blob/42728c0730229daad922372f76e08f5e40c31aa1/src/librustc_mir_build/build/matches/test.rs#L227. I am probably handling matching on u128
wrong.
Minimal repro for ICE:
fn is_true(a: true) -> u8 {
if a { 1 } else { 0 }
}
Minimal miscompilation repro:
fn main() {
let options = [1u128];
match options[0] {
1 => (),
0 => loop {},
v => panic(v),
};
}
fn panic(v: u128) -> !{
panic!("{}", v)
}
Got to metadata writing with the miscompilation fixed. It panicked in ppv-lite86
. Currently recompiling with the simd feature of ppv-lite86
disabled.
It finally works! :tada: :balloon: :rocket: :balloon: :tada:
Rust fork: bjorn3/rust@9a1facc469515a4b51bc463c36e65d001c26baa9
cg_clif commit: 8051242b0574ac57bdefa6b8b3b6dc69743c09c0
Cranelift commit: strike>bjorn3/wasmtime@430ab52a3cf9c941783e7996cb6dd00206e9152a</strike merge bjorn3/wasmtime@8fbde92c387635908955a5a8140a8901861cdade and bjorn3/wasmtime@ed0495c75440a1b593685491da157d79250afa02 (pr bytecodealliance/wasmtime#1559 + pr bytecodealliance/wasmtime#1939 (merged), clone it to the parent dir of the rust repo, or edit Cargo.toml of the rust repo to point to it in the patch section)
Edit has_cpuid
in corearch
to always return false.
Clone https://github.com/cryptocorrosion/cryptocorrosion/ into the cg_clif dir and patch utils-simd/ppv-lite86/src/lib.rs
to always user the fallback implementation and never the SIMD implementation.
config.toml:
[build]
full-bootstrap = true
[rust]
codegen-backends = ["cranelift"]
deny-warnings = false
Build completed successfully in 2:57:19
The bootstrap conpiler compiled an optimized compiler with cg_clif support using LLVM. This took 30m. This compiler with cg_clif support compiles a conpiler which is effectively less optimized than an LLVM debug build. This took 4m40s. This unoptimized comiler then took 3h to compile libstd+compiler.
bytecodealliance/wasmtime#1939 got merged. The only Cranelift blocker is now bytecodealliance/wasmtime#1559.
bytecodealliance/wasmtime#1559. has been merged. As of #1068 it is no longer necessary to patch cg_clif or Cranelift.
what's left for compiling rustc then?
Edit has_cpuid in corearch to always return false. Clone https://github.com/cryptocorrosion/cryptocorrosion/ into the cg_clif dir and patch utils-simd/ppv-lite86/src/lib.rs to always user the fallback implementation and never the SIMD implementation.
With #1070 merged, only https://github.com/bjorn3/rust/compare/3b4a3d68b5d3026bab9d41fcc004439207ecff90...9a1facc469515a4b51bc463c36e65d001c26baa9 should be necessary now.
I rebased and cleaned up the rust branch (now called cg_clif_subtree2
): https://github.com/bjorn3/rust/commit/faee9abe5113e53946d9b42d00e3194de90c087f It works together with cg_clif commit 4757371aba4e8aaf2cebb4ba32299cf7f9364aaf. No other changes are necessary anymore. There are still a few hacks on the rust side though.
stage | std | rustc | cg_clif |
---|---|---|---|
0 | 46.68s | 28m 40s | 2m 52s |
1 | 41.43s | 4m 25s | 51.42s |
2 | 19m 55s | 115m 09s | 21m 35s |
Build completed successfully in 2:36:43
I’m curious - how much longer are those times with llvm?
Stage 0 is using a cg_llvm compiled rustc with cg_llvm as backend. This is representative for all stages when using cg_llvm. Stage 1 is using a cg_llvm compiled rustc with cg_clif as backend. Stage 2 is using a cg_clif compiled rustc with cg_clif as backend.
The difference between stage 0 and stage 1 is the compile time speedup of cg_clif over release mode cg_llvm. The difference between stage 1 and stage 2 is the runtime slowdown of cg_clif over release mode cg_llvm. This difference is much less when using cg_llvm in debug mode. I don't volunteer for testing the difference between cg_clif and debug mode cg_llvm as it would take me ~4-5h, during which I can't use my computer at all. :)
Brilliant - thank you for the explanation! Incredible results.
@bjorn3 in stage 0, are you re-compiling llvm from scratch or do you have it cached? IIRC it's compiled only once for all three stages so to give a fair comparison between cg_llvm and cg_clif, one needs to ensure it's not compiled during the stage 0 build but cached.
I didn't compile LLVM at all. Stage 0 is the compilation of a rustc that only supports cg_clif using the bootstrap compiler.
@vultix On reddit you said 7x faster. This is pretty much comparing apples to oranges. cg_clif compiles code that runs a bit slower than debug mode cg_llvm. The compilation of rustc was however with release mode cg_llvm. This seems to have caused a bit of confusion on reddit.
@bjorn3 amazing!
Ah, my apologies for confusing everyone. That distinction never occurred to me
After #78624 all you need to do is apply
diff --git a/compiler/rustc_data_structures/Cargo.toml b/compiler/rustc_data_structures/Cargo.toml
index 23e689fcae7..5f077b765b6 100644
--- a/compiler/rustc_data_structures/Cargo.toml
+++ b/compiler/rustc_data_structures/Cargo.toml
@@ -32,7 +32,7 @@ tempfile = "3.0.5"
[dependencies.parking_lot]
version = "0.11"
-features = ["nightly"]
+#features = ["nightly"]
[target.'cfg(windows)'.dependencies]
winapi = { version = "0.3", features = ["fileapi", "psapi"] }
and run
$ cat > config.toml <<EOF
[build]
full-bootstrap = true
[rust]
codegen-backends = ["cranelift"]
EOF
$ ./x.py build --stage 2
Currently fails while compiling libcore using the new compiler with: