Meta-DCE for JS+WASM

[kripken]

This starts to use binaryen's wasm-metadce tool in -Os and -Oz, which lets us remove unused code along the boundary of wasm and JS. That is, it can remove things which doing DCE separately on each can't, like cycles between the two worlds.

For example, if wasm imported a JS function, then if the wasm optimizer manages to remove all uses of it, this lets us remove it not just from wasm but also from the JS side too. And the same works the other way as well.

So far, in -Os this shrinks hello world's .js by 3% and .wasm by 18%. This is less effective on large programs, since the removable runtime overhead is smaller - e.g. when using C++ iostreams, it shrinks by 7% / 1%. But where this really shines is on small programs like the testcase in #5836, that just do a little pure computation and don't need a runtime at all: this shrinks that .js by 5% and the .wasm by 84% (mostly thanks to getting rid of malloc/free!). The absolute numbers are interesting for the wasm, it goes from 10,729 bytes to just 1,740, which is getting us most of the way to emitting a really minimal wasm for such inputs. This reason this doesn't get us all the way is because:

• We need to represent JS's full graph of reachability for wasm-dce to be maximally effective. Currently this just represents imports and exports by parsing them directly. So interesting cycles on the JS side can't be collected yet.
• We still export a lot of things by default, which prevents this dead code elimination from eliminating them. So as we improve that (JS and wasm shrinking (testcase #1) #5836 etc.) this will get more powerful.

On the other hand, this does increase compile times noticeably, mostly on tiny files: 47% for hello world and 23% for C++ iostreams. That's why I think this makes sense to do in -Os and -Oz, but not other modes.

[nmrugg]

Personally, I would like this for -O3 as well since I have found that it produces much faster code than -Os and -Oz. Perhaps there could be another flag to enable this. I don't really care about compile times.

[kripken]

Yeah, I think it's reasonable to do this in -O3 too. That's a mode where people are ok with slow compile times anyhow. And the smaller code can lead to faster startup, which matters on some benchmarks, I see a 1% improvement in JS parse times in the iostream testcase for example.

But @nmrugg I'm curious where you saw it produce much faster code? I wouldn't expect that to be noticeable.

[nmrugg]

In Stockfish.js I see a big difference.

With -O3 Stockfish.js can run go depth 15 in under 2 seconds on my computer, but with -Oz, it takes around 5 seconds (-Os is the same).

I can post details if you want to investigate.

[nmrugg]

Perhaps I should note that those numbers are for asm.js. When compiled to WASM, -O3 takes about 0.6 seconds and -Oz takes about 1.6 seconds. (I haven't pushed my WASM branch to that repo yet.)

[kripken]

Got it, thanks. Makes sense to me now, I misunderstood what you wrote before.

[kripken]

Feedback here and offline has been positive, merging.