From 18c9539f7ea561285c3eaa12d75e45fd686c4450 Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 10:12:18 -0700 Subject: Add "Why not use LLVM IR" to FAQ --- FAQ.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'FAQ.md') diff --git a/FAQ.md b/FAQ.md index b2ef8ef..9f53de0 100644 --- a/FAQ.md +++ b/FAQ.md @@ -165,3 +165,46 @@ together in a number of configurations: * When WebAssembly [gains the ability to access garbage-collected objects](FutureFeatures.md#gcdom-integration), those objects will be shared with JS, and not live in a walled-off world of their own. +## Why not just use LLVM bitcode as a binary format? + +The [LLVM](http://llvm.org/) compiler infrastructure has a lot to recommend it: it has an existing intermediate +representation (LLVM IR) and binary encoding format (bitcode). It has code generation backends targeting +many architectures is actively developed and maintained by a large community. In fact [PNaCl](http://gonacl.com) +already uses LLVM as a basis for its binary format. However the goals and requirements that LLVM was designed +to meet are subtly mismatched with those of WebAssembly. + +WebAssembly has several requirements and goals for its IR and binary encoding: + * Portability: The IR must be the same for every machine architecture. + * Stability: The IR and binary encoding must not change over time (or change only in ways that can + be kept backward-compatible). + * Small encoding: The representation of a program should be as small as possible for transmission over + the Internet. + * Fast decoding: The binary format should be fast to decompress and decode for fast startup of programs. + * Fast compiling: The IR should be fast to compile (and suitable for either AOT or JIT) for fast startup + of programs. + +LLVM IR was designed for use primarily as an offline compiler. It is meant to make compiler optimizations +easy to implement, and to represent the constructs and semantics required by C, C++, and other languages +on a large variety of operating systems and architectures. This means that by default the IR is not portable +(the same program has different representations for different architctures) or stable (it changes over +time as optimization and language requirements change). It has representations for a huge variety +of information that is useful for implementing mid-level compiler optimizations but is not useful +for code generation (but which represents a large surface area for codegen implementers to deal with). +LLVM's binary format (bitcode) was designed for temporary on-disk serialization of the IR for link-time +optimization, and not for stability or compressibility (although it does have some features for both +of those). LLVM's code generation backends are designed to generate the best possible code, rather +than to generate code quickly, and the common software infrastructure in the LLVM project is designed +to be easy to use and modify rather than to be as fast as possible; this means that code generation +using LLVM's existing backends is slow. + +None of these problems is insurmountable. For example PNaCl defines a small portable subset of the IR +and a stable version of the bitcode encoding, and employs several techniques to improve startup +performance. However, each customization, workaround, and special solution means less benefit from +the common infrastructure. We believe that by taking our experience with LLVM and designing an IR and +binary encoding for our goals and requirements, we can do much better than adapting a system desgined +for other purposes. + +Note that this discussion applies to LLVM's IR and backend code. LLVM's clang frontend and midlevel +optimizers can still be used to generate WebAssembly code from C and C++, similarly to how PNaCl +and Emscripten do today. + -- cgit v1.2.3