Live data from Hacker News

QBE vs. LLVM

c9x.me

91–100 of 101 posts

Re: QBE vs. LLVM

#91
One important thing to note is that QBE emits text-based assembly and relies on a system-installed assembler. Meanwhile LLVM produces object files.

Re: QBE vs. LLVM

#92
post #72

I would love to have a way to bootstrap LLVM. This looks promising but I'm guessing a C++ frontend is much more challenging than writing this backend. gcc used to be the missing link, but they switched to C++ and now you can't bootstrap it with something like tcc.

Can't you still bootstrap LLVM from GCC, and GCC from the last C version, and that from tcc?

GNU GUIX works on the boostraping issue, they strive to reduce the seed size as much as possible: https://guix.gnu.org/blog/tags/bootstrapping/

Re: QBE vs. LLVM

#93

Doesn't allowing non-SSA forms like %v =w add %v, 1. defeat the purpose of using SSA in the first place? If this form is allowed, then I can not rely on `%v` having an immutable value which is much of the reason why we use SSA in the first place.

Not if the framework can readily create v0, v1 from the temporaries. It'll still end up as a full SSA according to what they describe.

Re: QBE vs. LLVM

#94
post #82

Earlier quoted context omitted.

Can you elaborate it a bit? I didn't see anything that suggested "rms didn't get the email because of the unique way he does email."

probably based on this: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I don't understand the bits about RMS' email configuration, but in that message in 2015 he indicated that he did not know about the offer in 2005 to give copyright of LLVM to the FSF.

Thanks for the source.

Re: QBE vs. LLVM

#95

Earlier quoted context omitted.

Not lock down people's devices basically. [L]GPLv3 requires that people are able to replace the [L]GPLv3'd binaries in their own devices if they want to (so they actually take advantage of the code being FLOSS instead of some nice theoretical novelty - ie. it is nice that my router uses Linux and find it amusing that it comes with the GPLv2 printed out, but what is the point if i can't open it up and fix/change some…

See also "Why is FreeBSD deprecating GCC in favor of Clang/LLVM?": * https://unix.stackexchange.com/questions/49906/why-is-freebs... GPL3 is more restrictive than GPL2, which in turn is more restrictive than BSD/MIT, in the name of allowing other freedoms for end-users.

Thanks, this link seems quite comprehensive and the answer author tries to write in a neutral voice - appreciated!

Re: QBE vs. LLVM

#96
post #8

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…

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…

Better documented doesn't mean the documentation is perfect. My experience two years ago was: You're going to have questions, and it's going to be difficult to find answers.

LLVM is not KISS. Very, very far from it.

Re: QBE vs. LLVM

#97

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…

You have other options. You could design your own bytecode, and write an interpreter. You could emit C, and use a C compiler. If you use LLVM, you also need to decide whether you want to link against LLVM and use the C++ API. Or you can use bindings for another language. Or you can emit IR as plain text, then feed that into the LLVM compiler.

I have done the latter, and would advise against it. The IR is powerful, but quite involved. The documentation is sometimes lacking. It's an interesting project, but you probably won't get far.

Linking against LLVM means you have to use their C++ interface, and every time you rebuild your compiler, it's going to be slow, with all the templates they use. Your compiler will be a large executable (clang and zig are about 90 MB), and you'd have to rebuild that every time you change your compiler. I would hate having to do that in my spare time, which is why I went the other route.

LLVM is very powerful. There's all these optimizations you get, and debug info. But it's not free. The integration is going to be hard and you'll have to spend quite some time on it.

The next time I would start a language project I would build an interpreter in a dynamic language, and possibly even use a parser generator. https://craftinginterpreters.com/ has a nice path laid out. Focus on what you actually want to do. Once you get somewhere, once you actually like your language, once you actually start a project in your own language, and have an actual need for more, you can write another compiler with more bells and whistles.

Re: QBE vs. LLVM

#98

I wish something like this existed for garbage-collected languages. The closest thing I know of is the JVM (and other similar VMs), but I'm hoping for ahead-of-time compilation. The key difficulty in adding garbage collection to code emitted with tools like this is being able to accurately tell what the root set is. (I know LLVM has support for this in theory, but I have found nothing that tells how to actually use i…

There's a version of the JDK that provides AOT.

Re: QBE vs. LLVM

#99
> QBE is extremely hackable.

and

> it is programmed in non-fancy C99 without any dependencies.

These are contradictions. C99 is not a "very hackable" language. If the compiler isn't designed to make fast binaries then they should have written it in a higher level language that has less foot guns.

Re: QBE vs. LLVM

#100

I wish something like this existed for garbage-collected languages. The closest thing I know of is the JVM (and other similar VMs), but I'm hoping for ahead-of-time compilation. The key difficulty in adding garbage collection to code emitted with tools like this is being able to accurately tell what the root set is. (I know LLVM has support for this in theory, but I have found nothing that tells how to actually use i…

https://docs.oracle.com/en/java/javase/15/docs/specs/man/jao...

I thought this wasn't universally available (that it was only in a special version of the JDK - https://openjdk.java.net/projects/graal/). But it appears to be everywhere, albeit experimentally.

Post reply on HN