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…
QBE vs. LLVM
21–30 of 101 posts
Re: QBE vs. LLVM
#22What I’d like something similar to QBE, but that actually compiles/targets LLVM.
So, essentially, a beginner-friendly intermediate layer on top of LLVM.
Re: QBE vs. LLVM
#23I’m going to be building a compiler over Christmas break, and I was thinking of targeting the LLVM toolset. This will be my second compiler; first one emitted x86 directly. Should I consider switching to QBE? I’m more focused on compiler passes that I want to write; register allocation, etc. is not my thing. I’m going to be working with CPS-conversion ans stuff like that. Does anyone have any good tutorials for using…
LLVM is much better documented than any other compiler system, so I would just KISS and use it. LLVM is a beast, though, but to get started I'd want to focus on the my side of the compiler first (the sema is where the pain is imo) Remember that there's no reason why you can't have an IR in between your language and the backend. If your language fits, (based on the CPS it probably won't but still) you can use a subset…
KISS is an acronym for 'keep it simple', which is an surprising choice of word when advocating for the much more complicated choice.
Re: QBE vs. LLVM
#24Earlier quoted context omitted.
Interesting. Programmers today do tend to think that LLVM is a revolutionary miracle, and border on worshipping it's creator.
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.
Re: QBE vs. LLVM
#25I’m going to be building a compiler over Christmas break, and I was thinking of targeting the LLVM toolset. This will be my second compiler; first one emitted x86 directly. Should I consider switching to QBE? I’m more focused on compiler passes that I want to write; register allocation, etc. is not my thing. I’m going to be working with CPS-conversion ans stuff like that. Does anyone have any good tutorials for using…
cranelift is a better alternative.
why?
Re: QBE vs. LLVM
#26Also 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…
There is also https://github.com/eclipse/omr
Re: QBE vs. LLVM
#27Also 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…
Re: QBE vs. LLVM
#28Earlier quoted context omitted.
LLVM is much better documented than any other compiler system, so I would just KISS and use it. LLVM is a beast, though, but to get started I'd want to focus on the my side of the compiler first (the sema is where the pain is imo) Remember that there's no reason why you can't have an IR in between your language and the backend. If your language fits, (based on the CPS it probably won't but still) you can use a subset…
KISS is an acronym for 'keep it simple', which is an surprising choice of word when advocating for the much more complicated choice.
Would you rather use a project you can at very least copy and paste from another codebase with, or - for what is basically the easy bit of the compiler - fiddle around with getting a (possibly more suitable backend in the long run, but you don't know that yet) much less mature project working.
Re: QBE vs. LLVM
#29Earlier 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.
If it was licensed under GPL, my bet is that Apple would not have adopted it at all.
That's entirely possible, but does it hurt their bottom line? They switched from GCC, because LLVM was available (to grow and eventually use).
Their aversion to the GPL seems mostly cultural, which is interesting given that we skewer microsoft for their sins along those lines 20 years ago now.
Re: QBE vs. LLVM
#30Earlier 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.
Hence why I said it was a sign of the future rather than a prediction. It's not going to get any better for software freedom, especially as we move into the cloud.
We live in a post-FSF world, I think people are taking for granted the bean counters playing nice with open source software.