Gracefully handle function body maximum size limit

[dschuff]

As discussed in WebAssembly/design#1138 browsers currently have a (fairly small) limitation on the maximum size of a wasm function body; small enough that (at least until another round of browser updates goes out) it is likely to affect some projects. So we should try to help those users out in emscripten.

At minimum, we should check all the body sizes after encoding, and warn the user if they are over the limit. That should be straightforward (it could be implemented in emscripten or binaryen).

Ideally we would also have some way to help them fix it, or just fix it for them. Presumably this would be some sort of outlining or function-splitting transformation. My understanding from previous discussion with @kripken is that the JS optimizer had such a transform for asm.js but that it was fragile and/or buggy. LLVM currently has MachineOutliner which operates on the MIR level and there was a recent proposal for a similar pass on LLVM IR although it's unclear how helpful those would be off-the-shelf, since their goal is somewhat different. LLVM does have a lower-level utility, CodeExtractor which might be used in a custom pass for function splitting.

[kripken]

There is a PR for warning about this in binaryen, WebAssembly/binaryen#1246

I have a good idea of how to do function splitting in binaryen, so I can do that if we want, but from the design issue I wasn't sure there was much interest? Was there more concern about this from browser vendors recently?

[kripken]

(If we do want to provide a function splitting option, then I think binaryen is the best place to do it, e.g. because of use cases like Go which can generate large functions and not use llvm, so a wasm2wasm splitter would be the most applicable.)

[dschuff]

I wouldn't say there has been any new concern; we discussed it at the in-person CG meeting, although most of the discussion (other than what is already in WebAssembly/design#1138) was about how to avoid the mismatch problem in the future. The plan of record is still to bump the limit up, but it will be a while before the next Edge update. I just have an AI from the meeting to follow up on this (and I had forgotten than you already did the warning in Binaryen), so I just filed this so I wouldn't forget.

[kripken]

Ok. Well, I think function splitting would be a few days of work in binaryen - happy to do that, if we think it makes sense. I wasn't sure based on the discussion I've heard so far, although the Go use case does seem like it raises the importance, but I'm unsure how much. My gut says to do it so we don't get stuck later.

[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 7 days. Feel free to re-open at any time if this issue is still relevant.