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(+) 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 From fdcbd3736c310d05ecbc2ba94b0725b71f1581ed Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 10:34:57 -0700 Subject: review --- FAQ.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/FAQ.md b/FAQ.md index 9f53de0..cad7bb2 100644 --- a/FAQ.md +++ b/FAQ.md @@ -180,13 +180,13 @@ WebAssembly has several requirements and goals for its IR and binary encoding: * 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. + * Fast compiling: The IR should be fast to compile (and suitable for either AOT- or JIT-compilation) 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 +(the same program has different representations for different architectures) 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). @@ -197,7 +197,8 @@ than to generate code quickly, and the common software infrastructure in the LLV 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 +None of these problems is insurmountable. For example PNaCl defines a small portable +[subset](https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi) 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 -- cgit v1.2.3 From 6f6ebc8f66246459e96854053cd9e78aec7dfcf3 Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 10:49:03 -0700 Subject: Add mention of UB and wordsmith a bit --- FAQ.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/FAQ.md b/FAQ.md index cad7bb2..3c4839a 100644 --- a/FAQ.md +++ b/FAQ.md @@ -182,6 +182,9 @@ WebAssembly has several requirements and goals for its IR and binary encoding: * 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-compilation) for fast startup of programs. + * Minimal [nondeterminsim](Nondeterminsism.md): The behavior of programs should be as predictable and + deterministic as possible (and should be the same on every architecture, a stronger form of the + portability requirement stated above). 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 @@ -190,6 +193,9 @@ on a large variety of operating systems and architectures. This means that by de 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). +It also has undefined behavior (largely similar to that of C and C++) which makes some classes of +optimization feasible or more powerful. + 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 @@ -199,11 +205,11 @@ using LLVM's existing backends is slow. None of these problems is insurmountable. For example PNaCl defines a small portable [subset](https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi) 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. +with reduced undefined behavior, and a stable version of the bitcode encoding. It also 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 -- cgit v1.2.3 From 7bf0be6f1cd004cfef73f29c875c85b8ee02d815 Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 10:50:36 -0700 Subject: fix typo in link --- FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FAQ.md b/FAQ.md index 3c4839a..63a83f4 100644 --- a/FAQ.md +++ b/FAQ.md @@ -182,7 +182,7 @@ WebAssembly has several requirements and goals for its IR and binary encoding: * 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-compilation) for fast startup of programs. - * Minimal [nondeterminsim](Nondeterminsism.md): The behavior of programs should be as predictable and + * Minimal [nondeterminsim](Nondeterminism.md): The behavior of programs should be as predictable and deterministic as possible (and should be the same on every architecture, a stronger form of the portability requirement stated above). -- cgit v1.2.3 From 72e173996c7af6838e363663f4820c00f636406c Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 10:52:40 -0700 Subject: Grammar! --- FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FAQ.md b/FAQ.md index 63a83f4..6f5e2bd 100644 --- a/FAQ.md +++ b/FAQ.md @@ -203,7 +203,7 @@ than to generate code quickly, and the common software infrastructure in the LLV 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 +None of these problems are insurmountable. For example PNaCl defines a small portable [subset](https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi) of the IR with reduced undefined behavior, and a stable version of the bitcode encoding. It also employs several techniques to improve startup performance. However, each customization, workaround, and special solution -- cgit v1.2.3 From f1dd19890a8389bda4f0d4b7f574748b5845b8e0 Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 10:58:05 -0700 Subject: Simplify first sentence about LLVM IR --- FAQ.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/FAQ.md b/FAQ.md index 6f5e2bd..207dee5 100644 --- a/FAQ.md +++ b/FAQ.md @@ -186,15 +186,15 @@ WebAssembly has several requirements and goals for its IR and binary encoding: deterministic as possible (and should be the same on every architecture, a stronger form of the portability requirement stated above). -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 architectures) 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). -It also has undefined behavior (largely similar to that of C and C++) which makes some classes of -optimization feasible or more powerful. +LLVM IR 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 architectures) 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). It also has undefined +behavior (largely similar to that of C and C++) which makes some classes of optimization feasible or +more powerful. 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 -- cgit v1.2.3 From 75735656794b47126748ba0b6f4dbc512910927f Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 11:33:05 -0700 Subject: Remove last sentence of LLVM description and merge paragraphs --- FAQ.md | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/FAQ.md b/FAQ.md index 207dee5..d59048a 100644 --- a/FAQ.md +++ b/FAQ.md @@ -194,14 +194,9 @@ language requirements change). It has representations for a huge variety of info 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). It also has undefined behavior (largely similar to that of C and C++) which makes some classes of optimization feasible or -more powerful. - -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. +more powerful. 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). None of these problems are insurmountable. For example PNaCl defines a small portable [subset](https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi) of the IR -- cgit v1.2.3 From e3d08be8cc86caf51edcdabfa7eca523b986a9cf Mon Sep 17 00:00:00 2001 From: Derek Schuff Date: Thu, 18 Jun 2015 12:51:58 -0700 Subject: Clarify UB as runtime unpredictability and IR as standard format --- FAQ.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/FAQ.md b/FAQ.md index d59048a..b75195b 100644 --- a/FAQ.md +++ b/FAQ.md @@ -194,9 +194,9 @@ language requirements change). It has representations for a huge variety of info 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). It also has undefined behavior (largely similar to that of C and C++) which makes some classes of optimization feasible or -more powerful. 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). +more powerful, but which can lead to unpredictable behavior at runtime. 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). None of these problems are insurmountable. For example PNaCl defines a small portable [subset](https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi) of the IR @@ -206,7 +206,7 @@ means less benefit from the common infrastructure. We believe that by taking our 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. +Note that this discussion applies to use of LLVM IR as a standardized format. LLVM's clang frontend +and midlevel optimizers can still be used to generate WebAssembly code from C and C++, and will use +LLVM IR in their implementation similarly to how PNaCl and Emscripten do today. -- cgit v1.2.3