summaryrefslogtreecommitdiff
path: root/test/wasm2js/br_table_to_loop.2asm.js.opt
Commit message (Collapse)AuthorAgeFilesLines
* wasm2js: Support for flexible module import naming (#5114)Sam Clegg2022-10-051-2/+1
| | | | | | | | The previous code was making emscripten-specific assumptions about imports basically all coming from the `env` module. I can't find a way to make this backwards compatible so may do a combined roll with the emscripten-side change: https://github.com/emscripten-core/emscripten/pull/17806
* Effects: Clarify trap effect meaning, and consider infinite loops to trap ↵Alon Zakai2022-09-161-1/+3
| | | | | | | | | | | | | | | | | | | | | due to timeout (#5039) I think this simplifies the logic behind what we consider to trap. Before we had kind of a hack in visitLoop that now has a more clear reasoning behind it: we consider as trapping things that trap in all VMs all the time, or will eventually. So a single allocation doesn't trap, but an unbounded amount can, and an infinite loop is considered to trap as well (a timeout in a VM will be hit eventually, somehow). This means we cannot optimize way a trivial infinite loop with no effects in it, while (1) {} But we can optimize it out in trapsNeverHappen mode. In any event, such a loop is not a realistic situation; an infinite loop with some other effect in it, like a call to an import, will not be optimized out, of course. Also clarify some other things regarding traps and trapsNeverHappen following recent discussions in https://github.com/emscripten-core/emscripten/issues/17732 Specifically, TNH will never be allowed to remove calls to imports.
* wasm2js: Don't assume that `env.abort` can always be impored. (#5049)Sam Clegg2022-09-161-3/+2
| | | | | | This import was being injected and then used to implement trapping. Rather than injecting an import that doesn't exist in the original module we instead use the existing mechanism to implement this as an internal helper.
* wasm2js: Have instantiate function take standard import object (#5018)Sam Clegg2022-09-141-1/+2
| | | | | | | | | | | Previously we were assuming asmLibraryArg which is what emscripten passes as the `env` import object but using this method is more flexible and should allow wasm2js to work with import that are not all form a single object. The slight size increase here is just temporary until emscripten gets updated. See https://github.com/emscripten-core/emscripten/pull/17737
* [wasm2js] Use native JavaScript Math.trunc (#3329)Max Graey2020-11-101-0/+1
|
* wasm2js: Remove global dict arguments to asmFunc (#3325)Sam Clegg2020-11-051-26/+13
|
* wasm2js: Skip heap creation in the absence of wasm memory. NFC (#3167)Sam Clegg2020-09-241-11/+16
| | | | | Also, format the asmFunc call to make it more readable in the ES6 modules case.
* wasm2js: Support exported tables (#3152)Sam Clegg2020-09-211-1/+0
|
* Stop emitting "almost asm" in wasm2js output (#2221)Alon Zakai2019-07-121-1/+0
| | | We don't ever emit "use asm" anymore, so this similar annotation is not really useful, it just increases size.
* wasm2js: remove unnecessary labels (#2108)Alon Zakai2019-05-151-1/+1
|
* wasm2js: optimize away unneeded load coercions (#2107)Alon Zakai2019-05-151-0/+1
|
* wasm2js: optimize loads (#2085)Alon Zakai2019-05-031-1/+0
| | | | When loading a boolean, prefer the signed heap (which is more commonly used, and may be faster). We never use HEAPU32 (HEAP32 is always enough), just remove it.
* wasm2js: run full optimizations during the pipeline (#2071)Alon Zakai2019-04-301-0/+42
We flatten for the i64 lowering etc. passes, and it is worth optimizing afterwards, to clean up stuff they created. That is run if the user ran wasm2js with an optimization level (like wasm2js -O3). Split the test files to check both optimized and unoptimized code.