Hacker News Reader

Comment by sitkack | Hacker News Reader

QBE is ... problematic. The source has no comments, single letter variable names. It is not written to be extended by anyone else other than the author.

I would recommend libfirm over QBE by at least 10km.

https://libfirm.github.io/ https://github.com/libfirm/libfirm

View on HN

It won't surprise you to learn that I'm always interested in hearing about alternatives to QBE, but from the documentation, libfirm sounds more like a heavyweight alternative to LLVM, not a lightweight alternative to QBE. How big is it?

9x larger in LoC, 50x larger in comments.

I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM.

Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments.

https://github.com/bytecodealliance/wasmtime/tree/main/crane...

If it's roughly an order of magnitude more complexity than QBE, it doesn't sound like an alternative, even if it's still two orders of magnitude smaller than LLVM.

Cranelift has been looking interesting. Also, LuaJIT.

We agree on a lot of things, but QBE is off the table. Complexity and kloc are loosely correlated. Cranelift and libfirm are of equivalent size while Cranelift is in Rust and has wonderful compiler engineers working on it.

https://c9x.me/git/qbe.git/tree/rega.c

QBE is a one person performance art project.

This code looks a lot like the Unix V6 kernel code or the source code to Steve Johnson's pcc C compiler. It's indeed too sparsely commented, but it's not as bad as you made it sound.

... and it is getting 70% of gcc speed...

On the topic of QBE, I've always felt that someone aiming to do the same scope of project ought to make their IR a syntactic subset of LLVM IR. If you do that, your test suite can involve invoking LLVM for a comparison.

As for QBE itself, many of the core transformations are fairly standard, which makes it somewhat more approachable for me (e.g. Cooper et al's dominance algorithm, Rideau et al's parallel moves algorithm, etc.). Of course, this doesn't negate the fact that it's not as "hackable" as they probably intended.

Missing RISC-V code generation.

But it is written in plain and simple C99, so it is at least much less toxic than LLVM.

I wonder how cparser (did not check if it was plain and simple C)+libfirm compare in performance to cproc+QBE on my benchmarks. May have to take some time to check that.

Whatever the results, it is always good to have, again, a real life alternative for optimizing C toolchains.

The main issues are the heavy usage of gcc extensions by linux (and glibc, etc).

Haven't used it, but this looks rather complete https://github.com/libfirm/libfirm/tree/master/ir/be/riscv

Oh... What I read did not mention that many backends. Don't read the doc, read the code... :(

Definitely worth some benchmarks, until libfirm SDK is reasonable: there is a bad start with cmake (c++) and I have no idea if it requires expensive dependencies (even if those are written in plain and simple C).

Reply on news.ycombinator.com