Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions site/source/docs/compiling/WebAssembly.rst
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@ To use fastcomp, just use the emsdk normally to get ``latest``. For the upstream
There are some differences you may notice between the two backends, if you upgrade from fastcomp to upstream:

* The wasm backend is strict about linking files with different features sets - for example, if one file was built with atomics but another was not, it will error at link time. This prevents possible bugs, but may mean you need to make some build system fixes.
* ``WASM=0`` behaves differently in the two backends. In fastcomp we emit asm.js, while in upstream we emit JS (since not all wasm constructs can be expressed in asm.js). Also, the JS support implements the same external ``WebAssembly.*`` API, so in particular startup will be async just like wasm by default, and you can control that with ``WASM_ASYNC_COMPILATION`` (even though ``WASM=0``).
* Also see the `blocker bugs on the wasm backend <https://github.com/emscripten-core/emscripten/projects/1>`_, and the `wasm backend tagged issues <https://github.com/emscripten-core/emscripten/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3A"LLVM+wasm+backend">`_.

Binaryen codegen options
Expand Down
16 changes: 13 additions & 3 deletions src/settings.js
Original file line number Diff line number Diff line change
Expand Up @@ -1067,9 +1067,11 @@ var EMSCRIPTEN_TRACING = 0;
var USE_GLFW = 2;

// Whether to use compile code to WebAssembly. Set this to 0 to compile to
// asm.js. This will fetch the binaryen port and build it. (If, instead, you
// set BINARYEN_ROOT in your ~/.emscripten file, then we use that instead of the
// port, which can useful for local dev work on binaryen itself).
// asm.js in fastcomp, or JS in upstream.
//
// Note that in upstream, WASM=0 behaves very similarly to WASM=1, in particular
// startup can be either async or sync, so flags like WASM_ASYNC_COMPILATION
// still make sense there, see that option for more details.
var WASM = 1;

// Whether to use the WebAssembly backend that is in development in LLVM. You
Expand Down Expand Up @@ -1139,6 +1141,14 @@ var WASM_MEM_MAX = -1;
// not block the main thread. This is currently required for all but the
// smallest modules to run in chrome.
//
// Note that this flag is still useful even if WASM=0 when using the upstream
// backend, as startup behaves the same there as WASM=1 (the implementation is
// of a fake WebAssembly.* object, so the startup code doesn't know it's JS
// and not wasm). That makes it easier to swap between JS and wasm builds,
// however, this is a difference from fastcomp in which WASM=0 always meant
// sync startup as asm.js (unless a mem init file was used or some other thing
// that forced async).
//
// (This option was formerly called BINARYEN_ASYNC_COMPILATION)
var WASM_ASYNC_COMPILATION = 1;

Expand Down