3 ms·
I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You ca
by Zababa 5y ago
I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.
- rlp 5y agoThere's a Cranelift backend, which is apparently faster at creating debug builds than LLVM: https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift
- pjmlp 5y agoOr Haskell, which also has multiple backends to choose from.
- mhh__ 5y agoThe D compiler has Walters last compilers backend. It is very useful to have a really fast debug build. It's also potentially remarkable how slow LLVM is given that the D compilers backend is actually pretty inefficient in places yet still munches LLVM on debug builds.
- user-the-name 5y agoThat is definitely not the case. Compiling C with LLVM is very fast. In Swift, type inference is one thing that can be extremely slow.
- Zababa 5y agoThat's fair, Crystal seems to also take a lot of time with type inference. However the LLVM codegen is almost constantly slower than the alternatives. For example, Haskell has a non-LLVM backend and a LLVM backend, and the LLVM backend is slower. Zig uses LLVM, and they are working on a non-LLVM backend to speed up development builds. A sibling comment mentioned that the situation is the same for D too. For C, I'm almost certain that TCC is faster than Clang with LLVM. There seems to be a pattern here. I'm not saying that LLVM is bad, in fact if it's used by so many projects it's for a reason. But it does have a cost.