QBE vs. LLVM • Hacker News Board

siraben wrote: post #7

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…

Writing backends to integration into compiler stacks like LLVM is as challenge unless one is quite deep into compilers.

If the idea is just to learn how they work, it is easier to just dump an IR that is compatible with a macro assembler, then just call the assembler with your macro definitions on the generated IR.

It won't win prices in performance, but one gets to learn how things work and will have a compiler with proper binaries at the end, and one can fine tune the macros to improve the quality of the code anyway.

Re: QBE vs. LLVM

#13

Post by tjansen » Wed, Dec 02, 2020, 8:27 AM UTC

I am also working on a compiler and need to decide on a backend soon. I currently plan to use C (clang) as IL in the first iteration, with the option to upgrade to LLVM IL later. I wonder whether there is any easier alternative. I definitely need to start with a framework that takes text input, because everything else would be hard to integrate with the TypeScript-based interpreter of my language. And it needs to work with a runtime written in C. QBE looks nicer than LLVM's IL, but I wonder whether it would cause more trouble in the end.

Re: QBE vs. LLVM

#14

Post by phendrenad2 » Wed, Dec 02, 2020, 9:28 AM UTC

pjmlp wrote: post #11

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…

Interesting. Programmers today do tend to think that LLVM is a revolutionary miracle, and border on worshipping it's creator.

Re: QBE vs. LLVM

#15

Post by beagle3 » Wed, Dec 02, 2020, 9:40 AM UTC

mhh__ wrote: post #10

siraben wrote: post #7

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…

Writing compiler backend in a declarative manner is something I've been toying with for a while now, and I don't think it's realistically possible with current technology. Backends are hard, unfortunately. However, since you are targeting the Z80, you might be able to just take the IR and transform it yourself? I haven't touched an LLVM backend for a while, so I don't know what the process is atm, but if you imagine…

It is not purely declarative, but Fraser & Hanson's lcc comes close while still delivering good optimization -- and has a book describing it (IIRC it was written literate-programming style).

It's been 20 years or more, I played with an older version that required an Icon interpreter as part of the build chain, and I think they had a later one that did away with that requirement.

The code generator is basically built from a declarative description of tree matching/rwriting templates with a cost model, and the compiler will find the optimal cost match.

Re: QBE vs. LLVM

#16

Post by MaxBarraclough » Wed, Dec 02, 2020, 9:41 AM UTC

ashton314 wrote: post #3

I’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…

What was your first compiler?

Re: QBE vs. LLVM

#17

Post by mhh__ » Wed, Dec 02, 2020, 9:43 AM UTC

phendrenad2 wrote: post #14

pjmlp wrote: post #11

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…

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.

Re: QBE vs. LLVM

#18

Post by Mutjake » Wed, Dec 02, 2020, 9:46 AM UTC

mhh__ wrote: post #17

phendrenad2 wrote: post #14

Earlier 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.

If it was licensed under GPL, my bet is that Apple would not have adopted it at all.

Re: QBE vs. LLVM

#19

Post by worldsayshi » Wed, Dec 02, 2020, 9:51 AM UTC

siraben wrote: post #4

ashton314 wrote: post #3

I’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…

Sounds like you want to compile a functional language. The best tutorial (in terms of being self-contained and being understandable in entirety) I've seen to compile FP to C is[0], I'd imagine that retargeting to LLVM wouldn't be that difficult either. [0] https://github.com/jozefg/pcf

Are there any big downsides to compiling to C instead of LLVM? I would assume that it would be less performant but it feels like a shallow preconception.

Re: QBE vs. LLVM

#20

Post by lattay » Wed, Dec 02, 2020, 9:51 AM UTC

tjansen wrote: post #13

I am also working on a compiler and need to decide on a backend soon. I currently plan to use C (clang) as IL in the first iteration, with the option to upgrade to LLVM IL later. I wonder whether there is any easier alternative. I definitely need to start with a framework that takes text input, because everything else would be hard to integrate with the TypeScript-based interpreter of my language. And it needs to wor…

Since this version of your language will never be used by thousands of users (if you ever hit sucess you’ll want to rewrite your compiler anyway) QBE is a lot simpler to use than LLVM. The main limitation is the limited set of target architecture, and probably the dlow development. In effect Linux AMD64 and ARM64 are the only well supported architectures. Also you may be able to compile to windows using mingw assembler.