summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactor expression runner so it can be used via the C and JS APIs (#2702)Daniel Wirtz2020-04-206-103/+493
| | | | | | | Refactors most of the precompute pass's expression runner into its base class so it can also be used via the C and JS APIs. Also adds the option to populate the runner with known constant local and global values upfront, and remembers assigned intermediate values as well as traversing into functions if requested.
* Fix issues with Types and Features (#2773)Thomas Lively2020-04-162-3/+7
| | | | | | | | | 1. Only emit exnref as part of a subtype if exception-handling is enabled in the fuzzer. 2. Correctly report that funcref and nullref require reference-types to be enabled. 3. Re-enable multivalue as a normal feature in the fuzzer. Possibly fixes #2770.
* Dummy interpreter support for EH (#2774)Heejin Ahn2020-04-161-6/+51
| | | | | | | | | | | | | | | | | | | | | | This adds dummy interpreter support for EH instructions, mainly for fuzzing. The plan is to make the interpreter support for EH instructions correctly using Asyncify in the future. Also to support the correct behavior we will need a `Literal` of `exnref` type too, which will be added later too. Currently what this dummy implementation does is: - `try`-`catch`-`end`: only runs `try` body and ignores `catch` body - `throw`: traps - `retyrow`: - Traps on nullref argument (correct behavior based on the spec) - Traps otherwise too (dummy implementation for now) - `br_on_exn`: - Traps on nullref (correct behavior) - Otherwise we assume the current expression matches the current event and extracts a 0 literal based on the current type. This also adds some interpreter tests, which tests the basic dummy behaviors for now. (Deleted tests are the ones that weren't tested before.)
* Validate that tuples have multiple operands (#2768)Thomas Lively2020-04-161-0/+2
| | | This was previously an unwritten and unchecked assumption.
* Fix OOB fuzzing (#2769)Alon Zakai2020-04-161-9/+15
| | | | | | | | | We should only do weird changes to the fuzz code if we allow out of bounds operations, because the OOB checks are generated as we build the IR, and changing them can remove the checks. (we fuzz 50% of the time with and 50% without OOBs, so this doesn't really hurt us)
* Emit tuples in the fuzzer (#2695)Thomas Lively2020-04-151-108/+170
| | | | | | | | Emit tuple.make, tuple.extract, and multivalue control flow, and tuple locals and globals when multivalue is enabled. Also slightly refactors the top-level `makeConcrete` function to be more selective about what it tries to make based on the requested type to reduce the number of trivial nodes created because the requested type is incompatible with the requested node.
* Enable cross-VM fuzzing + related improvements to fuzz_opt.py (#2762)Alon Zakai2020-04-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main benefit here is comparing VMs, instead of just comparing each VM to itself after opts. Comparing VMs is a little tricky since there is room for nondeterminism with how results are printed and other annoying things, which is why that didn't work well earlier. With this PR I can run 10's of thousands of iterations without finding any issues between v8 and the binaryen interpreter. That's after fixing the various issues over the last few days as found by this: #2760 #2757 #2750 #2752 Aside from that main benefit I ended up adding more improvements to make it practical to do all that testing: Randomize global fuzz settings like whether we allow NaNs and out-of-bounds memory accesses. (This was necessary here since we have to disable cross-VM comparisons if NaNs are enabled.) Better logging of statistics like how many times each handler was run. Remove redundant FuzzExecImmediately handler (looks like after past refactorings it was no longer adding any value). Deterministic testcase handling: if you run e.g. fuzz_opt.py 42 it will run one testcase and exactly the same one. If you run without an argument it will run forever until it fails, and if it fails, it prints out that ID so that you can easily reproduce it (I guess, on the same binaryen + same python, not sure how python's deterministic RNG changes between versions and builds). Upgrade to Python 3.
* Fix reuse of constant nodes in Precompute (#2764)Heejin Ahn2020-04-141-28/+33
| | | | | | | | | | Previously we tried to reuse `Const` node if a precomputed value is a constant node. But now we have two more kinds of constant node (`RefNull` and `RefFunc`), so we shouldn't reuse them interchangeably, meaning we shouldn't try to reuse a `Const` node when the value at hand is a `RefNull`. This correctly checks the type of node and tries to reuse only if the types of nodes match. Fixes #2759.
* Note removal of catch body in Vacuum (#2765)Heejin Ahn2020-04-141-0/+1
| | | | | | When it is certain that the try body does not throw, we can replace the try-catch with the try body. But in this case we have to notify the type updater that the catch body is removed, so that all parents' type should be updated properly.
* Fix build with a sprinkling of braces (#2766)Thomas Lively2020-04-141-11/+11
|
* Fix Atomics fuzz bugs in interpreter (#2760)Alon Zakai2020-04-131-22/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am working to bring up the fuzzer on comparisons between VMs. Comparing between the binaryen interpreter and v8, it found some atomics issues: Atomic operations, including loads and stores, must be aligned or they trap. AtomicRMW did the wrong thing with the operands. AtomicCmpxchg must wrap the input to the proper size (if we only load 1 byte, only look at 1 byte of the expected value too). AtomicWait and AtomicNotify must take into account their offsets. Also SIMDLoadExtend was missing that. This was confusing in the code as two getFinalAddresses existed, one that doesn't compute with an offset, and one that does. I renamed the one without to getFinalAddressWithoutOffset so it's explicit and we can easily see we only call that one on an instruction without an offset (which is the case for MemoryInit, MemoryCopy, and MemoryFill). AtomicNotify must check its address to see if it should trap, even though we don't actually have multiple threads running. Atomic loads of fewer bytes than the type always do an unsigned extension, not signed.
* Use direct pointers as Type IDs (#2745)Thomas Lively2020-04-135-115/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using indices into the global interned type table. This means that a lock is *never* needed to access an expanded Type. The Type lock is now only acquired when a complex Type is created. On a real-world wasm2js workload this improves wall clock time by 23% on my machine with 72 cores and makes traffic on the Type lock entirely insignificant. **Before** 72 cores real 0m6.914s user 184.014s sys 0m3.995s 1 core real 0m25.903s user 0m25.658s sys 0m0.253s **After** 72 cores real 5.349s user 70.309s sys 9.691s 1 core real 25.859s user 25.615s sys 0.253s
* Add --deterministic flag to wasm2js, for fuzzing (#2757)Alon Zakai2020-04-132-4/+31
| | | | | | | | | | | | | | | | | | | | | | In wasm2js we ignore things that trap in wasm that we can't really handle, like a load from memory out of bounds would trap in wasm, but in JS we don't want to emit a bounds check on each load. So wasm2js focuses on programs that don't trap. However, this is annoying in the fuzzer as it turns out that our behavior for places where wasm would trap was not deterministic. That is, wasm would trap, wasm2js would not trap and do behavior X, and wasm2js with optimizations would also not trap but do behavior Y != X. This produced false positives in the fuzzer (and might be annoying in manual debugging too). As a workaround, this adds a --deterministic flag to wasm2js, which tries to be deterministic about what it does for cases where wasm would trap. This handles the case of an int division by 0 which traps in wasm but without this flag could have different behavior in wasm2js with or without opts (see details in the patch).
* Fix invalid index checking in readImports (#2758)Heejin Ahn2020-04-131-1/+1
| | | Fixes #2751.
* Use std::cout for interpreter trap logging (#2755)Alon Zakai2020-04-131-1/+1
| | | | | | | | | | | | | | We used std::cerr as a workaround for that this logging interfered with spec testing. But it's easy enough to filter out this stuff for the spec tests. The benefit to using std::cout is that as you can see in the test output here, this is relevant test output - it's not a side channel for debugging. If the rest of the interpreter output is in std::cout but only traps are in std::cerr then they might end up out of order etc., so best to keep them all together. This will allow easier additions of tests for fuzz testcases
* Fuzz fix for SimplifyGlobals nopping (#2750)Alon Zakai2020-04-121-4/+4
| | | | We shouldn't actually nop, we forgot that the value may have side effects, so just drop it (opts will remove it later, if possible).
* Remove duplicate Type:: prefixes (NFC) (#2753)Heejin Ahn2020-04-123-11/+11
| | | | | | | | | These seem to be accidentally introduced in when we enforced use of `Type::` on type names in #2434. By the way TIL this actually compiles, and don't know why: ``` Type::Type::Type::Type::Type::Type::Type::Type::none ```
* Legalize return_calls properly (#2752)Alon Zakai2020-04-121-2/+4
| | | Fixes #2749
* Fix multivalue event fuzzing (#2748)Thomas Lively2020-04-101-2/+0
| | | | | The fuzzer was previously unconditionally emitting one event parameter more than it was supposed to, which meant multivalue events were emitted when multivalue was not enabled.
* Remove redundant vacume pass. Followup on #2741 (#2747)Sam Clegg2020-04-102-5/+19
| | | | Based on freedback in #2741 it looks like we can use the existing `simplify-globals-optimizing` pass to trigger this cleanups we need.
* Remove writes to globals that are never written to (#2741)Sam Clegg2020-04-092-0/+40
| | | | | Since the global is never read, we know that any write operation will be unobservable.
* Optimize uint32_t Type constructor (#2744)Thomas Lively2020-04-091-2/+5
| | | | | | Avoid taking the type interning lock to look up the size when the provided ID corresponds to a statically known type. This eliminates a considerable amount of unnecessary lock traffic when using the C or JS APIs.
* Handle tuples in Asyncify call support (#2743)Thomas Lively2020-04-093-9/+50
| | | | | Instead of adding globals for hardcoded basic types, traverse the module to collect all call types that might need to be handled and emit a global for each of them. Adapted from #2712.
* Remove function index printing (#2742)Thomas Lively2020-04-093-63/+53
| | | | | | | | `BinaryIndexes` was only used in two places (Print.cpp and wasm-binary.h), so it didn't seem to be a great fit for module-utils.h. This change moves it to wasm-binary.h and removes its usage in Print.cpp. This means that function indexes are no longer printed, but those were of limited utility and were the source of annoying noise when updating tests, anyway.
* Performance optimizations for Type (#2733)Thomas Lively2020-04-093-30/+57
| | | | | | | Cache type sizes in unused bits from the type ID and rewrite some Type methods to avoid unnecessary calls to `expand` when the type is known to be a basic non-tuple type. This eliminates most of the locking traffic and reduces wall clock time by 52% and CPU time by 73% percent for one real-world program on my machine.
* Fix an old misleading comment (#2738) [ci skip]Alon Zakai2020-04-091-2/+2
|
* Avoid g$ in main modules where possible (#2721)Alon Zakai2020-04-081-1/+28
| | | | | | | | | | We realized it is not valid to do these f$, g$ optimizations in main and side modules, as a symbol might appear in both (like RTTI or a weak symbol). We do need one of the appearances to "win". This does the g$ optimization in main modules only, that is, if a global appears in a main module then we can avoid a g$ import and instead compute its location directly in the module, since we will "win" over other modules with the same symbol anyhow.
* Run reorder-locals more in wasm2js (#2729)Alon Zakai2020-04-082-0/+6
| | | | | | | | | | | coalesce-locals is nonlinear in the number of locals, so it is greatly beneficial to reorder the locals (which then drops the unused ones at the end automatically). The default passes do this already, but wasm2js does some custom work, and this was missing. With this change that pass takes 10x less time on poppler with --flatten --flatten --simplify-locals-notee-nostructure which approximates what wasm2js does.
* Fix ReorderLocals handling of local names (#2728)Alon Zakai2020-04-081-2/+3
| | | | | I think the history here is that localNames used to be a vector, then we made it a map, but didn't update this pass... so in rare cases it could end up emitting wrong stuff.
* Work around a compiler issue on MacOS (#2730)Alon Zakai2020-04-081-7/+8
| | | | | | | | | | | | | | | | | | The post-commit Mac bot on github failed to compile #2727 with Undefined symbols for architecture x86_64: "wasm::ReorderLocals::UNSEEN", referenced from: wasm::ReorderLocals::doWalkFunction(wasm::Function*) in ReorderLocals.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) That seems odd, it's defined like this? static const Index UNSEEN = -1; Perhaps we are hitting a weird compiler bug. Anyhow, just use an enum to be safe. Also for clarity switch to 0 for the unseen value.
* Optimize ReorderLocals maps to vectors (#2727)Alon Zakai2020-04-071-8/+21
| | | | | | | | The original code here is quite old and I guess we assumed that it was ok to use maps for this, but on really huge amounts of locals it ends up mattering a lot. This makes the pass 3x faster on poppler after --flatten --flatten (double flatten creates lots of new locals, and is generally similar to what wasm2js does).
* Only do fp$ optimization in the main module (#2720)Alon Zakai2020-04-071-7/+11
| | | | | | | | Weak symbols and interposition etc. mean that we should not replace an fp$ call with a symbol from the module itself if there is a chance there is another symbol that would have overridden it. In side modules this risk exists and so this PR makes us stop doing that. In main modules it is ok because they are loaded first and so any symbol they provide will "win" over others anyhow.
* JS/Wasm BigInt support for wasm-emscripten-finalize (#2726)Alon Zakai2020-04-071-2/+10
| | | | | If wasm-emscripten-finalize is given the BigInt flag, then we will be using BigInts on the JS side, and need no legalization at all since i64s will just be BigInts.
* Do not emit multivalue events in fuzzer (#2723)Thomas Lively2020-04-031-2/+3
| | | | | | Unless the multivalue feature is enabled. The validation for events recently changed to disallow events returning multiple items unless the multivalue feature is enabled, but the fuzzer was not updated accordingly. This PR fixes the glitch.
* Tuple globals (#2718)Thomas Lively2020-04-0212-61/+120
| | | | | | | Since it wasn't easy to support tuples in Asyncify's call support using temporary functions, we decided to allow tuple-typed globals after all. This PR adds support for parsing, printing, lowering, and interpreting tuple globals and also adds validation ensuring that imported and exported globals do not have tuple types.
* Revert to using globals in Asyncify call support (#2719)Thomas Lively2020-04-011-71/+53
| | | | | | | | This reverts commit 5ddda8d2e6a3287ff6adcd69493e1e1c8b6c3872. We decided it would be easier to allow tuple-typed globals than to make calls work here after all. Reverts that change, but keeps small improvements it made for clarity.
* Avoid unnecessary fp$ in side modules (#2717)Alon Zakai2020-03-313-41/+55
| | | | | | | | | | | | | | | | Now that we update the dylink section properly, we can do the same optimization in side modules as in main ones: if the module provides a function, don't call an $fp method during startup, instead add it to the table ourselves and use the relative offset to the table base. Fix an issue when the table has no segments initially: the code just added an offset of 0, but that's not right. Instead, an a __table_base import and use that as the offset. As this is ABI-specific I did it on wasm-emscripten-finalize, leaving TableUtils to just assert on having a singleton segment. Add a test of a wasm file with a dylink section to the lld tests.
* Represent dylink section in IR, so we can update it. (#2715)Alon Zakai2020-03-305-15/+86
| | | | Update it from wasm-emscripten-finalize when we append to the table.
* Error out when EH is used in unsupported code (#2713)Heejin Ahn2020-03-273-0/+11
| | | | | This calls `Fatal()` when EH instructions are used in unsupported code. Currently EH instructions are unsupported in Flatten, ReReloop, and DataFlow-using passes.
* Avoid fp$ access in MAIN_MODULES (#2704)Alon Zakai2020-03-277-24/+98
| | | | | | | | | | | | | | | | Depends on emscripten-core/emscripten#10741 which ensures that table indexes are unique. With that guarantee, a main module can just add its function pointers into the table, and use them based on that index. The loader will then see them in the table and then give other modules the identical function pointer for a function, ensuring function pointer equality. This avoids calling fp$ functions during startup for the main module's own functions (which are slow). We do still call fp$s of things we import from outside, as we don't have anything to put in the table for them, we depend on the loader for that. I suspect this can also be done with SIDE_MODULES, but did not want to try too much at once.
* Tuple operations in C and JS APIs (#2711)Thomas Lively2020-03-263-66/+174
| | | | Adds functions for creating and inspecting tuple.make and tuple.extract expressions in the C and JS APIs.
* Convert Asyncify fake globals to fake calls. NFC (#2706)Alon Zakai2020-03-251-46/+71
| | | | | This will be easier to extend for tuples. Also add more clarifying comments.
* Disallow tuples in MVP (#2707)Thomas Lively2020-03-242-1/+11
| | | | | | | | | Previously the multivalue feature enabled tuples in control flow positions, but tuples elsewhere did not require the multivalue feature. However, allowing tuple operations and locals in MVP modules means that all passes and tools need to support tuples, even if it isn't a high priority for them to support multivalue. Allowing tuples in MVP modules doesn't provide much value, so this changes disallows them entirely unless multivalue is enabled.
* Fix Event section ordering (#2708)Thomas Lively2020-03-241-1/+1
| | | The version of V8 pulled in by JSVU recently updated to expect the new ordering of the event section, so this PR should fix the CI.
* Allow subtypes in tuple operations (#2700)Thomas Lively2020-03-231-10/+13
| | | | | | Some optimizations may replace tuple elements with simpler values, and those simpler values may be a subtype of the original value. Tuple operations should continue to validate without being refinalized in these cases.
* SIMD integer abs and bitmask instructions (#2703)Thomas Lively2020-03-2015-12/+204
| | | | | | Adds full support for the {i8x16,i16x8,i32x4}.abs instructions merged to the SIMD proposal in https://github.com/WebAssembly/simd/pull/128 as well as the {i8x16,i16x8,i32x4}.bitmask instructions proposed in https://github.com/WebAssembly/simd/pull/201.
* Emit unreachable tuple.make properly (#2701)Thomas Lively2020-03-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We previously thought unreachable `tuple.make` instructions did not require special unreachable handling, but consider the following wast: ``` (module (func $foo (tuple.make (unreachable) (i32.const 42) ) ) ) ``` This validates because the only expression in the body is unreachable, but when it is emitted as a binary it becomes ``` unreachable i32.const 42 ``` This does not validate because it ends with an i32, but the function expected an empty stack at the end. The fix is to emit an extra `unreachable` after unreachable `tuple.make` instructions. Unfortunately it is impossible to write a test for this right now because the binary parser silently drops the `i32.const 42`, making the function valid again.
* Support tuple locals in Asyncify (#2696)Thomas Lively2020-03-172-49/+70
| | | Iterate over tuple locals and separately load or store each component.
* makeConstExpression => makeConstantExpression (#2698)Alon Zakai2020-03-175-10/+12
| | | | | | The meaning we intend is "constant", and not the "Const" node (which contains a number). So I think the full name is less confusing.
* Fix binary emitting of signature indices (#2694)Thomas Lively2020-03-162-1/+4
| | | | | It should be a signed LEB128, not an unsigned LEB128. This bug was causing modules to be invalid when the number of signatures in the type section was large and multivalue blocks were present.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-09 22:13:26 +0000