Hacker News Reader

Comment by sylware | Hacker News Reader

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

View on HN

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

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

Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.

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.

I thought it was using libfirm... not that c++ diarrhea of llvm... :(

Relativity was discovered by a single guy.

Which confirms complex matters aren't an issue, being able to handle them might be.

wrong, point missed by miles away.

Maybe, "normal"/"average" devs would help you to get the point.

Those can keep up with Go, as per the language authors point of view regarding target audience.

AI????

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.

I made a facetious comment to parry that of pjmlp, whom also made a facetious comment wrt to compiler complexity and what "one person" can do.

https://github.com/seanbaxter/circle

It is like if one tried claiming that Fabrice Bellard was an example of a median dev.

The number of C++ compilers written by one person is one. And because of this, it gives us no predictive power in what pjmlp was trying to assert.

I agree with you, Albert and Lorentz and Riemann got caught in the rhetorical crossfire.

Not exactly the same but here https://github.com/robertoraggi/cplusplus there is one person serious effort to create a C++-23 compiler front end.

It does look serious, and is able to parse one simple case I got at hand that openwatcom and orangec failed, thanks for bringing it up.

Reply on news.ycombinator.com