Description
First of all: Thanks a lot for the positive reactions and thanks @vultix for this reddit post. Also thanks to all who donated.
Because I don't have a reddit account, I will reply to some of the comments here.
@cbmuser:
And I assume it’s x86_64 only.
to which @barsoap responded:
Also ARM and RISC-V.
At the moment Cranelift only supports x86_64 enough to use cg_clif I think. It may also support x86,
but I haven't tested it. ARM support is very incomplete and RISC-V support hasn't been tested by me.
@ClimberSeb:
Thanks for making me aware of this!
I thought bjorn3 was financed by Mozilla.
Nope, I am a student. :)
How close roughly is the project from being viable for integration / general use?
Once Cranelift supports TLS and Atomics
(both necessary for multi-threading) it should be possible to run most programs. For a non-exhaustive
list of programs which currently work please see bjorn3/rustc_codegen_cranelift#247.
I wholeheartedly applaud this effort, but in my experience the biggest slowdown in debug iteration builds for me is not compiling but linking. As soon as you get into projects with 500+ bigger dependencies linktimes are 30s+.
Switching to ld.lld helps a lot but we're still talking 10s+ per iteration. I keep wondering if there's a way to "cache linking" so a linker could skip most of the work when I change a single line impacting 2 variables...
I am aware of the linker time problem. It takes quite a lot of
time for the compilation of cg_clif itself. On MacOS the linker times are worse with cg_clif, but on
Linux cg_clif is more than twice as fast with linking. (on one benchmark)
Note: Only the cg_llvm and cg_clif (object + object sysroot) are relevant right anymore. I
recently removed the faerie backend.
For those who want to try this: The latest nightly changed some internal api's. I haven't yet updated
cg_clif for this, because my fix crashed the linker. For now you will have to use
rustc 1.42.0-nightly (175631311 2020-01-10). (rustup override set nightly-2020-01-09)