[discussion] JIT dynCall functions

[kripken]

This is probably not a good idea, but opening for discussion.

When we need to do a dynCall to something with an illegal type, we currently use a dynCall in the wasm, which means we have to generate those at compile time. Instead, this PR lets us JIT those dynCalls on demand. We create a tiny wasm binary that imports the table and that exports the new dynCall, cache that, and call it.

This would have the benefit of not creating any dynCalls at all during compile time which would help WebAssembly/binaryen#3043. However, it takes around 1-2ms to JIT each dynCall it seems, so potentially this is noticeably slow in a big project, and it probably uses more memory (but I actually didn't see anything obvious in my testing there).

This also can't quite remove all dynCalls. For asyncify we need to instrument the dynCalls for asyncify at compile time, so a JIT version is not good enough. And for wasm2js we'd need some more help as right now we go through a dynCall that is properly legalized, including calling setTempRet0 etc., so we'd need to add some mechanism to set the high bits inside the wasm2js module (which doesn't exist atm).

[sbc100]

I wonder if we could have hybrid approach of creating a single wrapper module containing the dynCalls ahead of time?

We could write the module out as part of wasm-emscripten-finalize --metadata-only (or whatever that ends up being called)?

If course this only works if we know at compile time which possible dynCalls we will need, but we currently rely on that today.

[kripken]

I wonder if we could have hybrid approach of creating a single wrapper module containing the dynCalls ahead of time?

Very interesting... yes, I think that would be practical, and better than this PR.

The question is whether we think it's worth it, I guess. The main downside is adding complexity. In particular for wasm2js it would be tricky to get right - it currently assumes a single wasm module that is replaced by a single JS "module" (that's a problem for both ideas).

I am leaning towards these solutions not being worth it, and -O0 builds will still do some work after link, while only -O0 -s WASM_BIGINT will not. I think we can get the docs and error messages clear enough. But I am sad there isn't a nice way without complexity to achieve -O0...

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[sbc100]

Looks like this idea resurfaced in #17328

[tlively]

Now that we have multi-memory in Binaryen, we can reintroduce wasm-merge. With wasm-merge, generating separate wrapper modules becomes nicer because in the optimizing path we can merge them into the main module so that the wrappers are included in optimizations.

cc @ashleynh