diff options
| -rw-r--r-- | doc/Makefile | 2 | ||||
| -rw-r--r-- | doc/llvm.txt | 99 |
2 files changed, 100 insertions, 1 deletions
diff --git a/doc/Makefile b/doc/Makefile index efa6294..e4c2d7a 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -1,6 +1,6 @@ .PHONY: all clean sync -DOCS = abi il +DOCS = abi il llvm all: $(DOCS:%=html/%.html) html/txt.css diff --git a/doc/llvm.txt b/doc/llvm.txt new file mode 100644 index 0000000..9dab26e --- /dev/null +++ b/doc/llvm.txt @@ -0,0 +1,99 @@ + =========== + QBE vs LLVM + =========== + + +Both QBE and LLVM are compiler backends using an SSA +representation. This document will explain why the +advanced stage in which LLVM is does not make QBE a +redundant project. Obviously, everything following is +probably biased, because written by me. + +- Scope +------- + +QBE is a much smaller scale projects with different +goals than LLVM. + + * QBE is for amateur language designers. + + It does not address all the problems faced when + conceiving an industry-grade language. If you are + toying with some language ideas, using LLVM will + feel like throwing your backpack in a truck, but + using QBE will feel more like biking. + + * QBE is about the first 70%, not the last 30%. + + It attempts to pinpoint, in the extremely vast + compilation literature, the optimizations that get + you 70% of the performance in 10% of the code needed + to scrape the last bits of performance. + + For example, copy propagation on SSA form is + implemented in 160 lines of code in QBE! + + * QBE is extremely hackable. + + First, it is, and will remain, a small project + (less than 8 kloc). Second, it is programmed in + non-fancy C99 without any dependencies. Third, + it is able to dump the IL and debug information in + a uniform format after each pass. + + On my Core 2 Duo machine, QBE compiles in half a + second. + +- Features +---------- + +LLVM is definitely more packed with features, but there +are a few things provided in QBE to consider. + + * LLVM does NOT provide full C compatibility for you. + + In more technical terms, any language that provides + good C compatibility and uses LLVM as a backend + needs to reimplement large chunks of the ABI in + its frontend! This well known issue in the LLVM + community causes a great deal of duplication + and bugs. + + Implementing a complete C ABI (with struct arguments + and returns) is incredibly tricky, and not really + a lot of fun. QBE provides you with IL operations + to call in (and be called by) C with no pain. + Moreover the ABI implementation in QBE has been + thoroughly tested by fuzzing and manual tests. + + * LLVM IR is more cluttered with memory operations. + + Implementing SSA construction is hard, and to save + its frontends from having to do it, LLVM provides + stack slots. This means that one increment of + a variable `v` will be composed of three LLVM + instructions: one load, one add, and one store. + + QBE provides simple non-SSA temporaries, so + incrementing `v` is simply done with one instruction + `%v =w add %v, 1`. + + This could seem cosmetic, but dividing the size of + the IL by three makes it easier for the frontend + writers to spot bugs in the generated code. + + * LLVM IR is more cluttered with type annotations and + casts. + + For the sake of advanced optimizations and + correctness, LLVM has complex IL types. However, + only a few types are really first class in the IL + and many operations of source languages require + casts to be compiled. + + Because QBE makes a much lighter use of types, the + IL is more readable and shorter. It can of course be + argued back that correctness of QBE is jeoparadized, + but remember that, in practice, the large amounts + of casts necessary in LLVM IL is compromizing the + overall effectiveness of the type system. |