On the same way than cproc+QBE I guess, 70% of gcc speed in my benchmarks.
The more real-life alternatives to those abominations of gcc and clang, the merrier.
I wish the linux kernel devs did care to keep the door _reasonably_ open for such compilers (with assembler source files as alternative to inline assembly, some extensions avoidance and niche expensive compiler features).
This is another case of why super complex syntax computer languages should be avoided like hell (c++, rust, etc).
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.
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?
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.
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.
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.
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.
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).
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).
Not really. Relativity goes back to Galileo at least, and it's development by Einstein relied on Lorentz and Riemann among others. Science really is a process of /standing on the shoulders of giants/ as Newton is reputed to have said.
That doesn't diminish Einstein's achievement of course.
The more real-life alternatives to those abominations of gcc and clang, the merrier.
I wish the linux kernel devs did care to keep the door _reasonably_ open for such compilers (with assembler source files as alternative to inline assembly, some extensions avoidance and niche expensive compiler features).
This is another case of why super complex syntax computer languages should be avoided like hell (c++, rust, etc).