There's a tutorial in development, but it's not finished yet. So right now isn't the optimal time for an HN post, but HN doesn't always ask people before linking to their projects ¯\_(ツ)_/¯.
"Cranelift is designed to be a code generator for WebAssembly, but it is general enough to be useful elsewhere too. The initial planned uses that affected its design are:
WebAssembly compiler for the SpiderMonkey engine in Firefox.
Backend for the IonMonkey JavaScript JIT compiler in Firefox.
Debug build backend for the Rust compiler."
Faster would be the most desirable attribute in my opinion. Rust should be much faster at least for development builds and LLVM is one of the parts which slows it down.
Does it, or are there plans to, translate the IR to WASM (i.e. a WASM backend instead of just frontend)? This seems to have a more expressive set of instructions than WASM and could be a good target for compilers.
It is something we're thinking about. You might have to limit yourself to a subset of the full Cranelift IR for this, but I think we could make that subset big enough to be interesting.
It's interesting that booleans are stored as 0 or -1 [1]. I wonder what drove that decision. I just checked, and Rust's LLVM stores booleans as 0 or 1.
That would only be true if `a` is guaranteed to be a non-zero value though, right? e.g. `x = some_bool ? 0 : 1` would not be able to be represented that way.
Sure, it doesn't prove a point, but the headline does show the level of growth Rust is enjoying... It's not that different than "game X on Linux" in the early days, or "ML in Python".
32 comments
[ 4.2 ms ] story [ 75.0 ms ] thread"Cranelift is designed to be a code generator for WebAssembly, but it is general enough to be useful elsewhere too. The initial planned uses that affected its design are:
WebAssembly compiler for the SpiderMonkey engine in Firefox. Backend for the IonMonkey JavaScript JIT compiler in Firefox. Debug build backend for the Rust compiler."
If it is to generate code with the same optimization quality and hardware support as LLVM, not really.
There are still cases where LLVM is playing catch up with GCC.
I also would like to see a pure Rust compiler toolchain, but sometimes pragmatism wins.
[1] https://cranelift.readthedocs.io/en/latest/ir.html#boolean-t...
C arguably picked the wrong semantics here. Hardware picks up the slack, however, with the setcc instructions on x86, csinc on AArch64, etc.
I assume someone once upon a time thought it was a nice thing for ~x to be equal to !x.