3 ms·

Be aware that cranelift is not a LLVM replacement (and isn't meant to be one). It's a fast but not-much-optimizing code gen which is complementing LLVM for the

Be aware that cranelift is not a LLVM replacement (and isn't meant to be one). It's a fast but not-much-optimizing code gen which is complementing LLVM for the use-case where you want to fastly spit out code but don't care much about optimizing it, beyond "simple"/"basic" optimizations. Besides that why do you think there should be LLVM IR to cranelift coversions? I just can't find any use-case for which is makes sense as it's always simpler and more efficient to generate cranelift IR from MIR instead of generating LLVM IR and then trying to convert it to cranelift.

atombender 6y ago
Is speed a specific goal of Cranelift? That is, can we expext that it will aim for fast compiles for ever, and not slowly accrue features and optimizations? From what I can tell, Cranelift was originally designed for Wasm, and that's still its primary purpose. That means that its goals might not be permanently aligned with that of Rust developers who desire a fast, non-optimizing backend.
- simcop2387 6y ago
  It might get further optimizations, but the fact that it's intended for a WASM JIT does mean that it's going to have to be optimizing towards compile speed, and avoiding regressions there-of. It might not ever completely and only target compile speed but you probably wouldn't want it to either, instead you'd want it to be a reasonably low-latency compiler back-end that does some optimizations so that the resulting code can actually run at a reasonable speed.
- dathinab 6y ago
  Like simcop2387 said, a codegen backend which is focused on wasm will likely never be "made slow". Wasm is in the end close to a form of high level assembly. Which means it is (should be) already preoptimized as much as needed/wanted/possible. Cranelift still needs to do some optimizations, especially wrt. platform specific aspects like register allocations and similar. In the end you don't want long load times when using wasm (at least in the web browser maybe in other places too). Through maybe in the future you might have some options to opt-in to some more time intensive optimizations for e.g. in browser gaming. But then rust could just not opt-in.

atombender 6y ago

Is speed a specific goal of Cranelift? That is, can we expext that it will aim for fast compiles for ever, and not slowly accrue features and optimizations? From what I can tell, Cranelift was originally designed for Wasm, and that's still its primary purpose. That means that its goals might not be permanently aligned with that of Rust developers who desire a fast, non-optimizing backend.

simcop2387 6y ago
It might get further optimizations, but the fact that it's intended for a WASM JIT does mean that it's going to have to be optimizing towards compile speed, and avoiding regressions there-of. It might not ever completely and only target compile speed but you probably wouldn't want it to either, instead you'd want it to be a reasonably low-latency compiler back-end that does some optimizations so that the resulting code can actually run at a reasonable speed.
dathinab 6y ago
Like simcop2387 said, a codegen backend which is focused on wasm will likely never be "made slow". Wasm is in the end close to a form of high level assembly. Which means it is (should be) already preoptimized as much as needed/wanted/possible. Cranelift still needs to do some optimizations, especially wrt. platform specific aspects like register allocations and similar. In the end you don't want long load times when using wasm (at least in the web browser maybe in other places too). Through maybe in the future you might have some options to opt-in to some more time intensive optimizations for e.g. in browser gaming. But then rust could just not opt-in.