QBE – a new compiler back end

QBE aims to be a pure C embeddable backend that provides 70% of the performance of advanced compilers in 10% of the code. Its small size serves both its aspirations of correctness and our ability to understand, fix, and improve it. It also serves its users by providing trivial integration and great flexibility.

http://c9x.me/compile/

>>1
Are you the author?

>>2
No, that would be mpu.
Why, do you have any questions?
Try finding him on eigenstate's IRC or emailing him a link to this thread so he can join us.

QBE #QBE

Why the fuck C? Analysis, compilation, and optimization is way better served by high level languages.

QBE is known to compile and pass its test suite on the following x64 operating systems.

Linux
FreeBSD
Mac OS X

>>1

Its small size serves both its aspirations of correctness and our ability to understand, fix, and improve it.

Mentifex level effort! But can it improve itself?

being meguka is suffering

As far toy compilers go, looks pretty nice. Is there a particular reason for textual representation of the SSA IR (aside from debugging)?

Apparent x86 specificity is kinda meh, but I guess that will be refactored into pluggable codegen at some point.

Another wart is that it's already larger than TCC (which supports 4 target CPUs and gcc asm intrinsics).

Moreover, TCC performs surprisingly well on modern superscalar cpu, especially on "general", branchy benchmarks (it will perform much worse on tight loop code thanks to high cache footprint). Maybe it might help to publish debian shootout of the two.

One could also argue that compilers are this all or nothing situation. Either write simple, non-optimizing single pass compiler, and spend the complexity on compatibility with gcc.

Or write aggressively optimizing compiler competing with llvm/gcc. If QBE goal is really the latter, then godspeed to you - sane llvm alternative would be especially nice.

Another wart is that it's already larger than TCC (which supports 4 target CPUs and gcc asm intrinsics).

I was gonna call you out on that but I think you're actually right. QBE is ``less than 8 kloc'', while the main logic of TCC is like 4-5 kloc. Also, doesn't TCC retarget by just having you recompile the whole thing but with a different target (no 'plug-and-play')?
Still, TCC also has its set of issues (register alloc..?, only few warnings etc.); I've also noticed problems when passing/returning structs...
I still use it as my 'main' (read: hobby) compiler, though.

I'm still pining for CompCert C. No more undefined behavior is better than a small compiler.

>>11

supports a subset of C

>>10

register alloc

It has essentialy none. It's the price you pay for single pass-ness (this also reduces overall complexity as there is no internal IR either - everything is emitted on the go). Same for error reporting being severely restricted by a single pass. As I elaborated before, TCC embraces the "all or nothing" ethos of compilers. It does not bother optimizing things at a cost of compiler complexity, because that'd be suddenly GCC/llvm competition it can't win.

However in terms of (supported features)/(compiler complexity) weight, it has no rival (yet?).

As for opaque struct passing, I suspect it's related to ABI (because there is no stable ABI for that, it's compiler specific). Things will definitely explode if you pass structs with something gcc linked.

retarget

This makes sense only in case when the compiler is enormous and resource intensive to build - like llvm.

With tcc, just compile each target as libtcc DSO, and dlopen you need to emit code for.

TCC is not particularly ABI and ANSI compliant, it's merely designed for "compile linux kernel", which is a practical benchmark of general useability.

>>12
It means that it only supports the reasonable subset. You can do an awful lot of shit in C that takes advantage of undefined behavior to hack together something that works but is buggy and exploitable as fuck. The goal is not to satisfy the whims over every currynigger who wants to implement the Seeples templating system with proprocessor hacks to automatically make tagged unions, but to make a compiler with consistent behavior that you know won't be doing stupid shit with your program at compile time.

Yet again, an object lesson on why trying to stay "small" or "bloat free" means you're writing shit with shitty limitations and shitty feature sets.

>>14
You don't know what you are talking about.

>>9,10
QBE is much smaller than TCC, c_count *.c in tinycc/ gives 25,000 lines containing code, in qbe/you get 5,400 lines. Comparing the "main logic of tcc" to QBE is nonsense, the "main logic" of tcc is a C parser, the "main logic" of QBE is a compiler backend, it simply does not make any sense to compare the two.

>>17
Indeed comparing the two is silly, as modern tcc has far, far more features (notably being able to replace whole GNU toolchain) compared to QBE.

So I picked tcc when it was around feature parity - more or less C99, plus some more - like existing preprocessor, assembler and ELF emitter.

bbd541d760251b2c1f76cf3992b5574ce99579ce circa 2002, and it has 7kloc.

>>16
Attempt to correct me then.