diff options
| author | Derek Schuff <dschuff@chromium.org> | 2015-06-18 12:51:58 -0700 |
|---|---|---|
| committer | Derek Schuff <dschuff@chromium.org> | 2015-06-18 12:51:58 -0700 |
| commit | e3d08be8cc86caf51edcdabfa7eca523b986a9cf (patch) | |
| tree | 1513dca18a7c1b3dd5ae3d34ade6bb8e46b0b791 /FAQ.md | |
| parent | 75735656794b47126748ba0b6f4dbc512910927f (diff) | |
| download | nanowasm-design-e3d08be8cc86caf51edcdabfa7eca523b986a9cf.tar.gz | |
Clarify UB as runtime unpredictability and IR as standard format
Diffstat (limited to 'FAQ.md')
| -rw-r--r-- | FAQ.md | 12 |
1 files changed, 6 insertions, 6 deletions
@@ -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. |