Comment by sylware
2 days ago
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.
https://libfirm.github.io/ https://github.com/libfirm/libfirm
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...
4 replies →
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
1 reply →
Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.
Relativity was discovered by a single guy.
Which confirms complex matters aren't an issue, being able to handle them might be.
3 replies →
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.
3 replies →
You mean Circle can output correct intermediate code for the latest gcc code? Or valve mesa aco code?
That frontend plugs into LLVM for the IR to machine code part, no need for GCC.
It replaces clang, it is not a fork of it.
1 reply →