41–50 of 101 posts
What I’d like something similar to QBE, but that actually compiles/targets LLVM. So, essentially, a beginner-friendly intermediate layer on top of LLVM.
You could transpile to C and feed that to LLVM/Clang or e.g. to TCC ( https://github.com/TinyCC/tinycc ).
I wanted to write an LLVM backend for various instruction sets (e.g. Z80, R216[0]), since those would deal with the problems of optimization passes and register allocation for me, but the LLVM tutorial[1] makes it look so goddamn hard. Does anyone know of a tutorial or of a declarative way to write such backends for either QBE or LLVM? The QBE git repository[2] has a few backends but also looks similarly involved. Co…
Earlier quoted context omitted.
You could transpile to C and feed that to LLVM/Clang or e.g. to TCC ( https://github.com/TinyCC/tinycc ).
Sure, but the idea is to avoid C and compile to a simplier IR, like qbe. And then compile that to native code in 1/10 of the time and memory LLVM or GCC do.
Earlier quoted context omitted.
why?
Because llvm is unusable for a dynamic language VM. The compile-times are too slow, it's way too big. cranelift is also big, but has sensible staged optimizers. I.e. it doesn't behave like java or llvm.
This is so true. Rust does it here: https://github.com/rust-lang/rust/tree/master/compiler/rustc... and it's a lot of code for no good reasons.
Earlier quoted context omitted.
why?
Because llvm is unusable for a dynamic language VM. The compile-times are too slow, it's way too big. cranelift is also big, but has sensible staged optimizers. I.e. it doesn't behave like java or llvm.
> Implementing a complete C ABI (with struct arguments and returns) is incredibly tricky, and not really a lot of fun. This is so true. Rust does it here: https://github.com/rust-lang/rust/tree/master/compiler/rustc... and it's a lot of code for no good reasons.
Even for non-toy compilers, I think it's a waste of human resources that every frontend has to implement the C ABI.
Earlier quoted context omitted.
LLVM does seem to be explicitly designed from the start to be "industry"-worthy rather than just academic research, though. It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. It's a shame it's not under the GPL, you can already see a sign of the future (present?) in apple not upstreaming their backends.
Apple doesn't upstream of their changes already, hence why you have a specific Apple column on cppreference. https://en.cppreference.com/w/cpp/compiler_support And the bitcode used by Apple Store for application delivery isn't 100% like the LLVM bitcode.
It looks to me like it’s the exact opposite, based solely on your link that is. Based on your link, they lag _behind_ upstream (vs being _ahead_ of upstream as you indicated) and don’t offer the same features, without a delay anyway, in “Apple Clang” that are in “Clang”.
Also to note, LLVM isn't the first compiler toolchain of its kind. Notable mentions, IBM's research project on PL.8 while developing their first RISC designs. https://rsim.cs.uiuc.edu/arch/qual_papers/compilers/auslande... https://pdfs.semanticscholar.org/3288/fc042cd474f0ec93d67753... https://rishiheerasing.net/modules/hca2102/paper/cocke.pdf The Amsterdam Compiler Toolkit, http://tack.sourceforge.net/ https://githu…
TenDRA is designed for front-ends to compile to ANDF, an "architecture-neutral distribution format" which is kind of like LLVM bitcode but different. Sadly it never really gained any lasting momentum as an open source project, though it currently has a few active maintainers.
And much more recently there's Cranelift https://github.com/bytecodealliance/wasmtime/tree/main/crane... which is written in Rust and is being used as a back-end for WebAssembly and Rust.