A possible new back end for Rust
jason-williams.co.uk
A possible new back end for Rust
1–10 of 224 posts
Re: A possible new back end for Rust
#2This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm.
I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t be assumed that just because llvm has an optimization that this optimization is profitable anywhere but llvm or at all.
Final thought, someone should try this with B3. https://webkit.org/docs/b3/
Re: A possible new back end for Rust
#3Does it support JIT compilation, i.e. specialization at runtime?
Re: A possible new back end for Rust
#4Does it support JIT compilation, i.e. specialization at runtime?
Cranelift has a JIT, but I am not sure what the status of it is as a rustc backend.
Re: A possible new back end for Rust
#5I've been wondering lately if the modern compilers should all be using C as the intermediate language (or some language-specific code optimization opportunities could be lost if they do that).
Re: A possible new back end for Rust
#6This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…
This is also why I think it was great that Maxime eventually graduated into GraalVM.
Another tool for compiler research using modern approaches with type safe languages.
Re: A possible new back end for Rust
#7While it appears that cg_clif is faster to compile, does it provide any performance benefit compared to cg_llvm? Are the compiled binaries as fast as llvm compiled binaries? If not is the use-case for development purposes only?
Re: A possible new back end for Rust
#8I've been wondering lately if the modern compilers should all be using C as the intermediate language (or some language-specific code optimization opportunities could be lost if they do that).
The semantics of C aren't very well defined, there is a lot of ambiguity in the form of undefined and implementation defined behaviour. This ambiguity is often needed to build an efficient optimizing compiler.
When you have a higher level language with more accurately defined semantics, running it all through C would risk introducing undefined behaviour.
With an IR you can control and define the semantics more closely to what your language needs.
Re: A possible new back end for Rust
#9>>"That’s Bjorn3, he decided to experiment in this area whilst on a summer vacation, and a year & half later single-handedly (bar a couple of PRs) achieved a working Cranelift frontend."
Is this guy human? This is amazing, and this guy should be given an award.
Re: A possible new back end for Rust
#10While it appears that cg_clif is faster to compile, does it provide any performance benefit compared to cg_llvm? Are the compiled binaries as fast as llvm compiled binaries? If not is the use-case for development purposes only?
Correct, cranelift is meant for faster development build cycles
https://github.com/bytecodealliance/wasmtime/blob/da02c913cc...