diff options
author | Alon Zakai <azakai@google.com> | 2019-10-23 15:09:11 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2019-10-23 15:09:11 -0700 |
commit | bb41564ff8a495d19a6d41ffe7f057f241e9739c (patch) | |
tree | f514726dea55bbb8f22903b4df59334b37a9e320 /scripts/test/wasm2js.py | |
parent | 760904ab458aa73d97fe4bea848caf8070c56571 (diff) | |
download | binaryen-bb41564ff8a495d19a6d41ffe7f057f241e9739c.tar.gz binaryen-bb41564ff8a495d19a6d41ffe7f057f241e9739c.tar.bz2 binaryen-bb41564ff8a495d19a6d41ffe7f057f241e9739c.zip |
Add ModAsyncify* passes (#2404)
These passes are meant to be run after Asyncify has been run, they modify the
output. We can assume that we will always unwind if we reach an import, or
that we will never unwind, etc.
This is meant to help with lazy code loading, that is, the ability for an
initially-downloaded wasm to not contain all the code, and if code not present
there is called, we download all the rest and continue with that. That could
work something like this:
* The wasm is created. It contains calls to a special import for lazy code
loading.
* Asyncify is run on it.
* The initially downloaded wasm is created by running
--mod-asyncify-always-and-only-unwind: if the special import for lazy code
loading is called, we will definitely unwind, and we won't rewind in this binary.
* The lazily downloaded wasm is created by running --mod-asyncify-never-unwind:
we will rewind into this binary, but no longer need support for unwinding.
(Optionally, there could also be a third wasm, which has not had Asyncify run
on it, and which we'd swap to for max speed.)
These --mod-asyncify passes allow the optimizer to do a lot of work, especially
for the initially downloaded wasm if we have lots of calls to the lazy code
loading import. In that case the optimizer will see that those calls unwind,
which means the code after them is not reached, potentially making lots of code
dead and removable.
Diffstat (limited to 'scripts/test/wasm2js.py')
0 files changed, 0 insertions, 0 deletions