Emscripten's use of wasm-opt

[jlb6740]

It was initially my understanding that "wasm-opt" is run by emscripten when compiling high level code either from c or rust (for example) to Wasm. I put "wasm-opt" in quotes because when I picked up this notion, the context was as if the wasm-opt used by emscripten here was not exactly the same wasm-opt as the standalone version. Specifically I've assumed that some or all of the optimizations done by the standalone version of wasm-opt provided by binaryen were simply baked into the optimization passes provided by emscripten .. but that they weren't exactly the same set or implementation of the optimizations. I now assume that assumption was wrong, but I don't know where this relationship is explained. I see sometimes package READMEs referencing setting BINARYEN_ROOT as if emscripten looks for and uses that to find wasm-opt but I am not sure that is the case and further more I am not sure how to tell emscripten which optimizations to perform. I also see wasm-opt in emsdk directory but I don't know how or if this is being used if nor how to specify specific optimizations from wasm-opt if it is.

Currently I have a stand-alone Wasm binary that has exceptions. Even though there is no JS involved (as the comments in the source implies there needs to be), the optimization --post-emscripten seems to improve the efficiency of my binary due to the optimizeExceptions pass. @s3ththompson I (A) would like some help understanding what analysis this pass is doing to know what is an unnecessary invoke related to exception throws and what are the checks these calls doing when they are necessary. I (B) would like to know how to run this optimization from an emcc command directly (what flags to use) either using the wasm-opt I compile myself from this repo or from the one included when downloaded from emsdk. (C) I would like to know if it makes sense to pursue embedding a similar optimization into emscripten (or maybe llvm to be more specific)? (D) Do optimizations graduate or get promoted from binaryen to emscripten?

[tlively]

The wasm-opt invoked by Emscripten is the exact same as the standalone wasm-opt from this repo. Generally if you pass e.g. -O2 to Emscripten, it will pass -O2 to both clang (at compile time) and wasm-opt (at link time), so the optimization pipelines are the same as well, besides additional passes Emscripten might run such --post-emscripten. You can tell emcc to run extra binaryen passes with the -sBINARYEN_EXTRA_PASSES=... setting.

You can see the precise exception optimizations the --post-emscripten pass here: https://github.com/WebAssembly/binaryen/blob/main/src/passes/PostEmscripten.cpp#L249-L341. Notably, this only applies to Emscripten exceptions, which call out to JS to do try-catch, as opposed to Wasm exceptions, which handle exceptions directly inside WebAssembly. Using Emscripten exceptions probably doesn't make much sense in a standalone Wasm module.

Briefly, the pass is finding cases where it can prove the callee of an invoke call will not throw, then optimizing those cases to be direct calls rather than "indirect" calls through the imported invoke functions.

I would like to know if it makes sense to pursue embedding a similar optimization into emscripten (or maybe llvm to be more specific)?

Probably not, since this optimization is only useful for the legacy Emscripten exceptions. New code would ideally use Wasm exceptions instead.

Do optimizations graduate or get promoted from binaryen to emscripten?

Emscripten only runs optimizations via clang and binaryen, but no, we generally don't migrate optimizations from binaryen to LLVM. It's not that we're opposed to improving optimizations in the LLVM WebAssembly backend, but that it's hard to prioritize when the same optimizations already work in wasm-opt.

[jlb6740]

Thanks @tlively. This covered everything. I do have a point of confusion now as to why I have seen performance improvements and a reduction in calls and exception handling code when running --post-emscripten only if this optimization is only relevant for emscripten exceptions which call to JS to do the try-catch. The obvious answer is that I am attributing the speed-up and code changes to the wrong transformation, but I need to understand this. I'll dig further and hopefully clarify my misunderstanding and any conclusions if they are interesting. Thanks!

[kripken]

Diffing the wasm text format before and after --post-emscripten should be a quick way to see what it changes.