summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* SIMD load and extend instructions (#2353)Thomas Lively2019-09-2415-10/+278
| | | | | | Adds support for the new load and extend instructions. Also updates from C++11 to C++17 in order to use generic lambdas in the interpreter implementation.
* v128.andnot instruction (#2355)Thomas Lively2019-09-2413-10/+42
| | | | | As specified at https://github.com/WebAssembly/simd/pull/102. Also fixes bugs in the JS API for other SIMD bitwise operators.
* vNxM.load_splat instructions (#2350)Thomas Lively2019-09-2325-56/+479
| | | | | | | Introduces a new instruction class, `SIMDLoad`. Implements encoding, decoding, parsing, printing, and interpretation of the load and splat instructions, including in the C and JS APIs. `v128.load` remains in the `Load` instruction class for now because the interpreter code expects a `Load` to be able to load any memory value type.
* Show the unescaped name in Asyncify pattern warnings (#2351)Alon Zakai2019-09-231-3/+5
| | | | | | | | | This is part of the fix for https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket.appspot.com/8901492015302662960/+/steps/Emscripten_testsuite__upstream__other_/0/stdout Specifically it fixes that the name shown there should not be escaped. Followup for #2344
* wasm-emscripten-finalize: Add more checking of __data_end global (#2352)Sam Clegg2019-09-231-0/+3
|
* asyncify: support *-matching in whitelist and blacklist (#2344)Beuc2019-09-232-37/+76
| | | See emscripten-core/emscripten#9381 for rationale.
* Revert part of #2281 to allow the possiblity of building under python2 (#2349)Sam Clegg2019-09-231-1/+1
| | | | | | | | Even though we do support python3 and if the python in your path happens to be python3 that will work just fine, we also want to continue to support those users who still only have python2 (i.e. mac users who are relying on the default system python). See https://github.com/emscripten-core/emsdk/issues/356
* Mark C API as dllexports on Windows (#2342)Michal Strehovský2019-09-211-905/+1022
| | | | | On Windows, symbols have to be explicitly exported to make them visible/accessible in a shared library. Binaryen.dll currently doesn't export any symbols as a result. Marking all exported methods as `BINARYEN_API` that is defined as `__declspec(dllexport)` on Windows, unless building a static library.
* Fix typo in Asyncify (#2346)Beuc2019-09-191-2/+2
|
* Add a --standalone-wasm flag to wasm-emscripten-finalize (#2333)Alon Zakai2019-09-183-1/+38
| | | The flag indicates that we want to run the wasm by itself, without JS support. In that case we don't emit JS dynCalls etc., and we also emit a wasi _start if there is a main, i.e., we try to use the current conventions in the wasm-only space.
* SIMD narrowing and widening operations (#2341)Thomas Lively2019-09-1416-25/+542
|
* SimplifyGlobals: Apply known constant values in linear traces (#2340)Alon Zakai2019-09-133-14/+83
| | | | | | | | | | | | | This optimizes stuff like (global.set $x (i32.const 123)) (global.get $x) into (global.set $x (i32.const 123)) (i32.const 123) This doesn't help much with LLVM output as it's rare to use globals (except for the stack pointer, and that's already well optimized), but it may help on general wasm. It can also help with Asyncify that does use globals extensively.
* Add asserts in Asyncify (#2338)Alon Zakai2019-09-131-7/+84
| | | | | With the optional asserts, we throw if we see an unwind begin in code that we thought could never unwind (say, because the user incorrectly blacklisted it). Helps with emscripten-core/emscripten#9389
* Replace python command with python3 (#2281)Markus Koschany2019-09-131-1/+1
|
* Fix bitselect operation in C/JS APIs (#2336)Daniel Wirtz2019-09-112-1/+3
| | | In #2328 the SIMDBitselect API has been replaced with SIMDTernary that now has Bitselect as one of multiple operations, which is currently not exposed, unlike the new QFMA/QFMS operations which are exposed. This PR adds it.
* More response file support in asyncify: whitelist/blacklist (#2335)Alon Zakai2019-09-081-2/+10
|
* Properly handle fastcomp *wasm* safe heap (#2334)Alon Zakai2019-09-061-1/+6
| | | | | Properly handle fastcomp wasm safe heap: emscripten_get_sbrk_ptr is an asm.js library function, which means it is inside the wasm after asm2wasm, and exported. Find it via the export.
* Handle sbrk import by emscripten+upstream in SafeHeap (#2332)Alon Zakai2019-09-061-10/+20
| | | | | To allow #2331 to roll, I forgot that upstream and fastcomp handle sbrk differently. This fixes that, and handles the upstream case where we import sbrk itself from JS. We can simplify this after emscripten-core/emscripten#9397 lands, however, it may also be nice to keep the backwards compatibility for running on existing wasm files in the wild.
* Print custom section contents if printable (#2326)Ingvar Stepanyan2019-09-061-0/+19
| | | This helps with debugging human-readable sections like sourceMappingURL.
* SafeHeap: Prepare for emscripten_get_sbrk_ptr (#2331)Alon Zakai2019-09-051-8/+22
| | | | | | | Currently emscripten links the wasm, then links the JS, then computes the final static allocations and in particular the location of the sbrk ptr (i.e. the location in memory of the brk location). Emscripten then imports that into the asm.js or wasm as env.DYNAMICTOP_PTR. However, this didn't work in the wasm backend where we didn't have support for importing globals from JS, so we implement sbrk in JS. I am proposing that we change this model to allow us to write sbrk in C and compile it to wasm. To do so, that C code can import an extern C function, emscripten_get_sbrk_ptr(), which basically just returns that location. The PostEmscripten pass can even apply that value at compile time, so we avoid the function call, and end up in the optimal place, see #2325 and emscripten PRs will be opened once other stuff lands. However, the SafeHeap pass must be updated to handle this, or our CI will break in the middle. This PR fixes that, basically making it check if env.DYNAMICTOP_PTR exists, or if not then looking for env.emscripten_get_sbrk_ptr, so that it can handle both.
* [wasm2js] Fix memory.size (#2330)Alon Zakai2019-09-051-11/+19
| | | | | | | We emitted the __wasm_memory_size function only when memory growth was enabled, but it can be used without that too. In theory we could only emit it if either memory growth or memory.size is used, but I think we can expect JS minifiers to do that later. Also fix a test suite bug - the check/auto_update script didn't run all the wasm2js tests when you run it with argument wasm2js (it used that as the list of tests, instead of the list of files, which confused me here for a while...).
* Add an option for the PostEmscripten pass to set the sbrk ptr location ↵Alon Zakai2019-09-041-2/+29
| | | | | | | (which is called DYNAMICTOP_PTR in emscripten) (#2325) The assumption is that an import env.emscripten_get_sbrk_ptr exists, and we replace the value returned from there with a constant. (We can't do all this in wasm-emscripten-finalize, as it happens before the JS compiler runs, which can add more static allocations; we only know where the sbrk ptr is later in compilation.) This just replaces the import with a function returning the constant; inlining etc. can help more later. By setting this at compile time we can reduce code size and avoid importing it at runtime, which makes us more compatible with wasi (less special imports).
* Wasi followups to #2323 (#2329)Alon Zakai2019-09-033-6/+3
| | | | | Remove wasi, as only wasi_unstable makes sense. Also remove shared constant for wasi as we don't know yet if it'll be needed later.
* QFMA/QFMS instructions (#2328)Thomas Lively2019-09-0325-136/+275
| | | | | | | | | Renames the SIMDBitselect class to SIMDTernary and adds the new {f32x4,f64x2}.qfm{a,s} ternary instructions. Because the SIMDBitselect class is no more, this is a backwards-incompatible change to the C interface. The new instructions are not yet used in the fuzzer because they are not yet implemented in V8. The corresponding LLVM commit is https://reviews.llvm.org/rL370556.
* Add mutable parameter to global imports in C/JS API (#2317)Daniel Wirtz2019-09-033-5/+8
|
* Minify wasi imports and exports, and not just "env" (#2323)Alon Zakai2019-09-013-5/+17
| | | This makes the minification pass aware of "wasi_unstable" and "wasi" as well.
* Support response files, and use that in Asyncify (#2319)Alon Zakai2019-08-304-2/+34
| | | See emscripten-core/emscripten#9206, the asyncify names can need complex escaping, so this provides an escape hatch.
* Followup to workaround for minification of wasm2js mem init (#2318)Brion Vibber2019-08-301-3/+3
| | | | | | | | | | | | | Emscripten's minifier mis-minifies a couple bits in the memory init function that's used with wasm2js when not using an external memory init file: https://github.com/emscripten-core/emscripten/issues/8886 Previous fix worked around the bug in one place but failed to account for another. Have now confirmed that it works with this change in place. Updated test cases to match.
* Add missing new features to the C and JS APIs (#2312)Daniel Wirtz2019-08-283-0/+10
|
* Allow all features on wasm2js and add atomic tests (#2311)Heejin Ahn2019-08-282-11/+7
| | | | | | This adds `-all` argument to wasm2js testing and fixes wasm2js to actually take that argument (currently it doesn't, when it takes a wast file). This also adds a wasm2js test for `atomic.fence` instruction that was added in #2307.
* Add atomic.fence instruction (#2307)Heejin Ahn2019-08-2726-17/+186
| | | | | | | This adds `atomic.fence` instruction: https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#fence-operator This also fix bugs in `atomic.wait` and `atomic.notify` instructions in binaryen.js and adds tests for them.
* Do not hoist truncation of wasm2js divisions (#2305)Thomas Lively2019-08-261-2/+4
| | | | | | It is not valid to defer the truncation of divisions because accumulated non-integral results can produce different values when they are combined before truncation. This was causing a test failure in the Rust test suite.
* Remove test output from source tree (#2114)Sam Clegg2019-08-211-1/+1
|
* Support --version argument in command line tools (#2304)Sam Clegg2019-08-201-0/+9
|
* Add initial support for anyref as an opaque type (#2294)Jay Phelps2019-08-2027-25/+146
| | | | | | | | | | | | | Another round of trying to push upstream things from my fork. This PR only adds support for anyref itself as an opaque type. It does NOT implement the full [reference types proposal](https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md)--so no table.get/set/grow/etc or ref.null, ref.func, etc. Figured it was easier to review and merge as we go, especially if I did something fundamentally wrong. *** I did put it under the `--enable-reference-types` flag as I imagine that even though this PR doesn't complete the full feature set, it probably is the right home. Lmk if not. I'll also be adding a few github comments to places I want to point out/question.
* Fix infinite loop in AsmConstWalker::visitCall (#2303)Guanzhong Chen2019-08-161-1/+7
|
* Remove code to handle EM_ASM and setjmp/longjmp (#2302)Guanzhong Chen2019-08-161-135/+30
| | | | | | | | | This reverts commit 12add6f17c377de7ac334e8fa7885b61b98f3db4 (#2283). This is done due to the complexity of supporting EM_ASM and setjmp/longjmp, especially with dynamic linking thrown into the mix. In https://reviews.llvm.org/D66356, using EM_ASM and setjmp/longjmp in the same function is now an error.
* wasm2js: Fix switch lowering, don't fall through after the hoisted parts (#2301)Alon Zakai2019-08-161-38/+18
| | | | | The switch lowering will "hoist" blocks of code into the JS switch when it can. If it can hoist some but not others, it must not fall through into those others (while it can fall through the hoisted ones - they began as nested blocks with falling-through between them). To fix this, after the hoisted ones issue a break out of the switch (which now contains all the hoisted code, so breaking out of it gets to the code right after the hoisted ones). fixes #2300
* Add basic exception handling support (#2282)Heejin Ahn2019-08-1328-80/+1209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds basic support for exception handling instructions, according to the spec: https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md This PR includes support for: - Binary reading/writing - Wast reading/writing - Stack IR - Validation - binaryen.js + C API - Few IR routines: branch-utils, type-updating, etc - Few passes: just enough to make `wasm-opt -O` pass - Tests This PR does not include support for many optimization passes, fuzzer, or interpreter. They will be follow-up PRs. Try-catch construct is modeled in Binaryen IR in a similar manner to that of if-else: each of try body and catch body will contain a block, which can be omitted if there is only a single instruction. This block will not be emitted in wast or binary, as in if-else. As in if-else, `class Try` contains two expressions each for try body and catch body, and `catch` is not modeled as an instruction. `exnref` value pushed by `catch` is get by `pop` instruction. `br_on_exn` is special: it returns different types of values when taken and not taken. We make `exnref`, the type `br_on_exn` pushes if not taken, as `br_on_exn`'s type.
* Add missing copy in Copier::visitPush (#2295)Heejin Ahn2019-08-111-1/+3
| | | It seems this was missing in #2289.
* Followups to #2292, code cleanups for opt-utils.h (#2293)Alon Zakai2019-08-091-24/+18
|
* Support empty export names in wasm2js and JS mangling in general (#2290)Alon Zakai2019-08-091-0/+6
|
* Duplicate Import Elimination (#2292)Alon Zakai2019-08-096-46/+126
| | | | | | | | | | | | | This is both an optimization and a workaround for the problem that emscripten-core/emscripten#7641 uncovered and had to be reverted because of. What's going on there is that wasm-emscripten-finalize turns emscripten_longjmp_jmpbuf into emscripten_longjmp (for some LLVM internal reason - there's a long comment in the source that I didn't fully follow). There are two such imports already, one for each name, and before that PR, we ended up with just one. After that PR, we end up with two. And with two, the minification of import names gets confused - we have two imports with the same name, and the code there ends up ignoring one of them. I'm not sure why that PR changed things - I guess the wasm-emscripten-finalize code looks at the name, and that PR changed what name appears? @sbc100 maybe #2285 is related? Anyhow, it's not trivial to make import minification code support two identical imports, but I don't think we should - we should avoid having such duplication anyhow. And we should add an assert that they don't exist (I'll open a PR for that later when it's possible). This fixes the duplication by adding a useful pass to remove duplicate imports (just functions, for now). Pretty simple, but we didn't do it yet. Even if there is a wasm-emscripten-finalize bug we need to fix with those duplicate imports, I think this pass is still a good thing to add. I confirmed that this fixes the issue caused by that PR.
* Fix EM_ASM not working with setjmp/longjmp (#2283)Guanzhong Chen2019-08-091-30/+135
|
* Copying fixes (#2289)Alon Zakai2019-08-071-2/+4
| | | | | We didn't have an OverriddenVisitor in the copying code, and sadly unimplemented visitors just return null. That explains the crash in #2288 The missing visitors were push and pop.
* wasm-emscripten-finalize: Remove reliance on name section (#2285)Sam Clegg2019-08-062-4/+5
| | | | | | | | There were a couple of places where we were relying on internal names and therefore a name section. After this change wasm-emscripten-finalize works correctly on binaries without a name section at all and only relies on the names of imports and exports.
* Remove trailing whitespaces after 'else' in stack IR (#2284)Heejin Ahn2019-08-061-1/+0
|
* Implement --check-stack-overflow flag for wasm-emscripten-finalize (#2278)Guanzhong Chen2019-08-023-4/+135
|
* Revert "Fix EM_ASM not working with setjmp/longjmp (#2271)" (#2277)Alon Zakai2019-08-011-128/+30
| | | | | This reverts commit 692f4666fd116fb7827b53348978f29bba253d47. See details in the reverted PR.
* Proper Asyncify list name handling (#2275)Alon Zakai2019-07-312-0/+45
| | | | | The lists are comma separated, but the names can have internal commas since they are human-readable. This adds awareness of bracketing things, so void foo(int, double) is parsed as a single function name, properly. Helps emscripten-core/emscripten#9128