[tinco]

Looks good! I know your target is 70% of the performance, but is there any fundamental reason to QBE that it couldn't be more? Suppose I ported my compiler from LLVM to QBE (I think I could do so with not too much effort) would at some point I be able to work on porting some of LLVMs optimizing phases to QBE to get my performance up to par, or is there a design decision you made that will get in the way of the last 30%?

[mpu]

It's only a goal I set to myself, if we can do better, heck let's do it! Keeping the code short, on the other hand, is really something I care about.

[tinco]

Great, I have the same goal for my compiler. I'd love for the compiler to be able to bootstrap its own backend, and as it only compiles C that would rule out llvm.

I am not sure how far I am along in actually compiling C, if I'd had to guess I'd say around 60%. Hopefully there's not too much crazy things on the horizon.

I'm not a C programmer myself so I first implemented the switch statement in a naieve way, and then I discovered the way they actually work and spent days getting it right.

If I get to the point where I can compile trivial C programs like the benchmarks game, I'll research a move to QBE :)

[gravypod]

If you modularize/abstract different optimization passes, you could easily keep code clarity high, while still having a very clean set of code.

I've not done this a lot in C but it looks possible: http://stackoverflow.com/questions/384121/creating-a-module-...