4 ms·

It's nice to see an LLVM alternative. I get the appeal of putting all of the optimizations in one place so that everyone can use them, but the concerns over an

It's nice to see an LLVM alternative. I get the appeal of putting all of the optimizations in one place so that everyone can use them, but the concerns over an LLVM monoculture are also valid. Now all that's missing is something to transform IR between LLVM and Cranelift, or vice-versa, to make them interchangeable.

ibraheemdev 6y ago
It looks like someone attempted a LLVM to Cranelift translator in 2019 [1]... but it is no longer maintained [1]: https://github.com/sunfishcode/llvm2cranelift https://github.com/sunfishcode/llvm2cranelift
gumby 6y ago
LLVM monoculture? People used to complain about the gcc monoculture, and LLVM hasn’t quite caught up with (the moving target of) gcc. Plus gcc has more front ends. I use them both and appreciate their different strengths. There’s no question that the existence of llvm spurred gcc to improve a lot, and vice versa.
- Ericson2314 6y ago
  "LLVM monoculture" as in LLVM being the backend for every niche language, not as in LLVM being the only way to compile C.
  - pjmlp 6y ago
    Before that we had the C monoculture, where the same authors would be generating Assembly like C code (C--) and calling the compiler into it. The most dangerous aspect of this is the cargo cult of not thinking out of the box regarding alternatives.
- da_big_ghey 6y ago
  I meant LLVM monoculture, not Clang monoculture. All the new languages use LLVM for a backend. (There are, of course, exceptions, but the point stands.)
- Hello71 6y ago
  gcc has more front ends? really? https://gcc.gnu.org/frontends.html https://gcc.gnu.org/frontends.html lists seven bundled frontends and eight third-party frontends, some of which "are very much works in progress", and none of which I have ever heard of anyone using. https://en.wikipedia.org/wiki/LLVM https://en.wikipedia.org/wiki/LLVM lists about twenty-five, most of which I have heard of.
  - Gaelan 6y ago
    Perhaps they mean backends?
  - woodruffw 6y ago
    I believe almost none of the frontends listed in that Wikipedia section are included in the main llvm-project tree. To the best of my knowledge, is only stable in-tree frontend is Clang, with Flang (for Fortran) in-tree but considered WIP. Clang, in turn, only supports C, C++, Obj-C, and Obj-C++, so that's 4 frontend languages. Edit: But yes, as 'Gaelan notes, I think they meant compiler backends.
    - Hello71 6y ago
      that's a different project organization style though. it's like saying that bsd has so much more functionality than linux just because more stuff is bundled. maybe the bsd way makes better software, maybe not, but it would be insane to say that openbsd has "more web server functionality" than debian because openbsd comes with httpd but on debian you have to install one.
dathinab 6y ago
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.

ibraheemdev 6y ago

It looks like someone attempted a LLVM to Cranelift translator in 2019 [1]... but it is no longer maintained [1]: https://github.com/sunfishcode/llvm2cranelift https://github.com/sunfishcode/llvm2cranelift

gumby 6y ago

LLVM monoculture? People used to complain about the gcc monoculture, and LLVM hasn’t quite caught up with (the moving target of) gcc. Plus gcc has more front ends. I use them both and appreciate their different strengths. There’s no question that the existence of llvm spurred gcc to improve a lot, and vice versa.

Ericson2314 6y ago
"LLVM monoculture" as in LLVM being the backend for every niche language, not as in LLVM being the only way to compile C.
- pjmlp 6y ago
  Before that we had the C monoculture, where the same authors would be generating Assembly like C code (C--) and calling the compiler into it. The most dangerous aspect of this is the cargo cult of not thinking out of the box regarding alternatives.
da_big_ghey 6y ago
I meant LLVM monoculture, not Clang monoculture. All the new languages use LLVM for a backend. (There are, of course, exceptions, but the point stands.)
Hello71 6y ago
gcc has more front ends? really? https://gcc.gnu.org/frontends.html https://gcc.gnu.org/frontends.html lists seven bundled frontends and eight third-party frontends, some of which "are very much works in progress", and none of which I have ever heard of anyone using. https://en.wikipedia.org/wiki/LLVM https://en.wikipedia.org/wiki/LLVM lists about twenty-five, most of which I have heard of.
- Gaelan 6y ago
  Perhaps they mean backends?
- woodruffw 6y ago
  I believe almost none of the frontends listed in that Wikipedia section are included in the main llvm-project tree. To the best of my knowledge, is only stable in-tree frontend is Clang, with Flang (for Fortran) in-tree but considered WIP. Clang, in turn, only supports C, C++, Obj-C, and Obj-C++, so that's 4 frontend languages. Edit: But yes, as 'Gaelan notes, I think they meant compiler backends.
  - Hello71 6y ago
    that's a different project organization style though. it's like saying that bsd has so much more functionality than linux just because more stuff is bundled. maybe the bsd way makes better software, maybe not, but it would be insane to say that openbsd has "more web server functionality" than debian because openbsd comes with httpd but on debian you have to install one.

dathinab 6y ago

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.