Emscripten: JS and wasm shrinking (testcase #1)

[kripken]

This issue tracks part of our shrinking initiative, which is Option 1 from #5794. The goal is to shrink the JS and wasm we emit by default. See details in that previous discussion.

To get things started, I looked at one testcase - we should look at more, hence the testcase #1 in the title, this is just to get started. The testcase is a "pure computation" library,
````

include

EMSCRIPTEN_KEEPALIVE
int add(int x, int y) {
return x + y;
}
``` and I built it with-Os --closure 1 -g1 -s WASM=1, then counted lines in the JS. Starting point: 10K of wasm and 24K of JS when fully minified, or when built as I did with-g1` for convenience, it is 32K, in 1,143 lines. In more detail:

• 232 lines: String and array utilities, ccall, cwrap #5892 (need more)
• 132 lines: wasm glue. #5859 #5907 (may need more)
• 109 lines: ENVIRONMENT setup stuff.
• 102 lines: Calling main + the hooks around that. #5850 (need more)
• 88 lines: Runtime object. #5954
• 55 lines: getValue/setValue. #5839
• 55 lines: Syscalls.
• 55 lines: Export stuff from asm (all the Module.x = get the thing from asm.x etc).
• 44 lines: Stack trace support. #5857
• 44 lines: addOnPreRun, runDependency etc, startup ordering stuff.
• 35 lines: Memory and view creation.
• 34 lines: allocate()
• 27 lines: Math fallbacks (imul, clz, trunc). #5837
• 27 lines: Mem init file loading. #5844
• 18 lines: invoke/dynCall stubs.

Also

• Meta-DCE #5919

If you want to work on one of these, open an issue or a PR, and we can add a link from here.

[curiousdannii]

I like this idea, and I might try to submit a PR for one or two.

I do think changes of this nature warrant a bump to version 1.38.0 if not 2.0.0. With no release descriptions or a dedicated news blog it will be important to signal that these changes are arriving.

Would it help to have a staging branch for them to be merged into before they all get merged into incoming?

[kripken]

We can mention this on the mailing list to get more attention, good idea. We can also try to have more tagged versions around them (helps bisection etc.), but that's being held up by problems on the bots that we just need more help with keeping green (so not sure if that will change).

Otherwise though I think that these changes shouldn't be that dangerous - at least the 3 PRs open so far are not - because they will give very clear error messages when assertions are on (and also in -O0 mode where assertions are on by default). Any breakage people encounter should be brief.

Any change that is more dangerous than that should be handled even more carefully, but hopefully we won't run into such a thing.

[kripken]

Mentioned on the mailing list: https://groups.google.com/forum/#!topic/emscripten-discuss/OY_6JCIjimc

[kripken]

5919 (meta-DCE, DCE across js+wasm) helps very significantly on this, shrinking the .js by 5% and the .wasm by 84%.

[kripken]

This testcase is basically done - we emit a tiny 42 byte wasm for it (compared to 10,837 bytes before), the best possible. I'm preparing a blogpost about the progress.

The work here has also helped other testcases as well, we should focus on them next.