summaryrefslogtreecommitdiff
path: root/src/wasm-interpreter.h
Commit message (Collapse)AuthorAgeFilesLines
* [GC] Fix trapping on array.new_data of dropped segments of offset > 0 (#7124)Alon Zakai2024-12-021-3/+12
| | | | Even if the size is 0, if the offset is > 0 then we should trap.
* Fix memory.grow bounds and overflow checks for mem64 (#7112)Thomas Lively2024-11-251-2/+7
| | | | | Previously the interpreter only executed overflow and bounds checks for memory.grow on 32-bit memories. Run the checks on 64-bit memories as well.
* [wasm64] Fix 32-bit address computation in execution of SIMDLoadExtend (#7068)Alon Zakai2024-11-081-3/+6
|
* Rename indexType -> addressType. NFC (#7060)Sam Clegg2024-11-071-11/+11
| | | See https://github.com/WebAssembly/memory64/pull/92
* [wasm64] Make interpreter table methods operate on Address, not Index (#7062)Alon Zakai2024-11-071-21/+13
| | | This allows 64-bit bounds checking to work properly.
* [wasm64] Fix 64-bit memory/table operations in interpreter (#7058)Alon Zakai2024-11-061-9/+14
| | | A bunch of places assumed a 32-bit index.
* [NFC] Use RAII to manage call depth tracking in the interpreter (#7049)Alon Zakai2024-11-011-27/+10
| | | | | | | The old code manually managed it for no good reason that I can see. After this, there is no difference between callFunction and callFunctionInternal, so fold them together.
* [NFC] Print type names in more places when logging (#6975)Alon Zakai2024-09-301-3/+3
|
* [FP16] Implement conversion operations. (#6974)Brendan Dahl2024-09-261-0/+8
| | | | | | | | | | Note: FP16 is a little different from F32/F64 since it can't represent the full 2^16 integer range. 65504 is the max whole integer. This leads to some slightly strange behavior when converting integers greater than 65504 since they become infinity. Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
* [NFC] Make the GCData constructor a move constructor (#6946)Alon Zakai2024-09-171-10/+13
| | | | | | | This avoids creating a large Literals (SmallVector of Literal) and then copying it. All the places that construct GCData do not need the Literals afterwards. This gives a 7% speedup on the --precompute benchmark from #6931
* [FP16] Implement madd and nmadd. (#6878)Brendan Dahl2024-09-031-0/+4
| | | | | | | | | | | | | | Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md A few notes: - The F32x4 and F64x2 versions of madd and nmadd are missing spect tests. - For madd, the implementation was incorrectly doing `(b*c)+a` where it should be `(a*b)+c`. - For nmadd, the implementation was incorrectly doing `(-b*c)+a` where it should be `-(a*b)+c`. - There doesn't appear to be a great way to actually implement a fused nmadd, but the spec allows the double rounded version I added.
* Rename relaxed SIMD fma instructions to match spec. (#6876)Brendan Dahl2024-08-271-8/+8
| | | | | | | The instructions relaxed_fma and relaxed_fnma have been renamed to relaxed_madd and relaxed_nmadd. https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md#binary-format
* [FP16] Implement unary operations. (#6867)Brendan Dahl2024-08-271-0/+14
| | | | Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
* Support more reference constants in wast scripts (#6865)Thomas Lively2024-08-261-3/+21
| | | | | | | | | | | | | | Spec tests use constants like `ref.array` and `ref.eq` to assert that exported function return references of the correct types. Support more such constants in the wast parser. Also fix a bug where the interpretation of `array.new_data` for arrays of packed fields was not properly truncating the packed data. Move the function for reading fields from memory from literal.cpp to wasm-interpreter.h, where the function for truncating packed data lives. Other bugs prevent us from enabling any more spec tests as a result of this change, but we can get farther through several of them before failing. Update the comments about the failures accordingly.
* [FP16] Implement arithmetic operations. (#6855)Brendan Dahl2024-08-211-0/+17
| | | | Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
* Support `ref.extern n` in spec tests (#6858)Thomas Lively2024-08-211-8/+5
| | | | | | | | | | | | | | | | | Spec tests pass the value `ref.extern n`, where `n` is some integer, into exported functions that expect to receive externrefs and receive such values back out as return values. The payload serves to distinguish externrefs so the test can assert that the correct one was returned. Parse these values in wast scripts and represent them as externalized i31refs carrying the payload. We will need a different representation eventually, since some tests explicitly expect these externrefs to not be i31refs, but this suffices to get several new tests passing. To get the memory64 version of table_grow.wast passing, additionally fix the interpreter to handle growing 64-bit tables correctly. Delete the local versions of the upstream tests that can now be run successfully.
* [Exceptions] Finish interpreter + optimizer support for try_table. (#6814)Sébastien Doeraene2024-08-201-11/+59
| | | | | | * Add interpreter support for exnref values. * Fix optimization passes to support try_table. * Enable the interpreter (but not in V8, see code) on exceptions.
* Implement table.init (#6827)Alon Zakai2024-08-161-20/+75
| | | | | Also use TableInit in the interpreter to initialize module's table state, which will now handle traps properly, fixing #6431
* [FP16] Implement relation operations. (#6825)Brendan Dahl2024-08-091-0/+12
| | | | Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
* [FP16] Implement lane access instructions. (#6821)Brendan Dahl2024-08-081-0/+6
| | | | Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
* [FP16] Implement load and store instructions. (#6796)Brendan Dahl2024-08-061-4/+33
| | | | Specified at https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
* [threads] ref.i31_shared (#6735)Thomas Lively2024-07-121-1/+2
| | | | | | | Implement `ref.i31_shared` the new instruction for creating references to shared i31s. Implement binary and text parsing and emitting as well as interpretation. Copy the upstream spec test for i31 and modify it so that all the heap types are shared. Comment out some parts that we do not yet support.
* Rename external conversion instructions (#6716)Jérôme Vouillon2024-07-081-3/+3
| | | | | | | | | Rename instructions `extern.internalize` into `any.convert_extern` and `extern.externalize` into `extern.convert_any` to follow more closely the spec. This was changed in https://github.com/WebAssembly/gc/issues/432. The legacy name is still accepted in text inputs and in the C and JS APIs.
* Fix TableFill bounds checking (#6621)Alon Zakai2024-05-211-9/+4
| | | The offsets are unsigned.
* Rewrite wasm-shell to use new wast parser (#6601)Thomas Lively2024-05-171-1/+1
| | | | | | | | | | | | | | | | | | Use the new wast parser to parse a full script up front, then traverse the parsed script data structure and execute the commands. wasm-shell had previously used the new wat parser for top-level modules, but it now uses the new parser for module assertions as well. Fix various bugs this uncovered. After this change, wasm-shell supports all the assertions used in the upstream spec tests (although not new kinds of assertions introduced in any proposals). Uncomment various `assert_exhaustion` tests that we can now execute. Other kinds of assertions remain commented out in our tests: wasm-shell now supports `assert_unlinkable`, but the interpreter does not eagerly check for the existence of imports, so those tests do not pass. Tests that check for NaNs also remain commented out because they do not yet use the standard syntax that wasm-shell now supports for canonical and arithmetic NaN results, and our interpreter would not pass all of those tests even if they did use the standard syntax.
* [Strings] Remove operations not included in imported strings (#6589)Thomas Lively2024-05-151-18/+17
| | | | | | The stringref proposal has been superseded by the imported JS strings proposal, but the former has many more operations than the latter. To reduce complexity, remove all operations that are part of stringref but not part of imported strings.
* [Strings] Remove stringview types and instructions (#6579)Thomas Lively2024-05-151-38/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The stringview types from the stringref proposal have three irregularities that break common invariants and require pervasive special casing to handle properly: they are supertypes of `none` but not subtypes of `any`, they cannot be the targets of casts, and they cannot be used to construct nullable references. At the same time, the stringref proposal has been superseded by the imported strings proposal, which does not have these irregularities. The cost of maintaing and improving our support for stringview types is no longer worth the benefit of supporting them. Simplify the code base by entirely removing the stringview types and related instructions that do not have analogues in the imported strings proposal and do not make sense in the absense of stringviews. Three remaining instructions, `stringview_wtf16.get_codeunit`, `stringview_wtf16.slice`, and `stringview_wtf16.length` take stringview operands in the stringref proposal but cannot be removed because they lower to operations from the imported strings proposal. These instructions are changed to take stringref operands in Binaryen IR, and to allow a graceful upgrade path for users of these instructions, the text and binary parsers still accept but ignore `string.as_wtf16`, which is the instruction used to convert stringrefs to stringviews. The binary writer emits code sequences that use scratch locals and `string.as_wtf16` to keep the output valid. Future PRs will further align binaryen with the imported strings proposal instead of the stringref proposal, for example by making `string` a subtype of `extern` instead of a subtype of `any` and by removing additional instructions that do not have analogues in the imported strings proposal.
* [interp] Make memory and table handling more consistency. NFC (#6582)Sam Clegg2024-05-131-83/+73
|
* [memory64] Add table64 to existing memory64 support (#6577)Sam Clegg2024-05-101-13/+24
| | | | | | | Tests is still very limited. Hopefully we can use the upstream spec tests soon and avoid having to write our own tests for `.set/.set/.fill/etc`. See https://github.com/WebAssembly/memory64/issues/51
* Respect the Web limitation on Table size (#6567)Alon Zakai2024-05-011-0/+4
| | | | | Without this the fuzzer can error on differences in behavior between V8 and us. Also move the limitations constants to their own header.
* [Strings] Limit string allocations like we do arrays (#6562)Alon Zakai2024-04-291-3/+8
| | | | | | | | When we concat strings, check if their length exceeds a reasonable limit. (We do not need to do this for string.new as that reads from an array, which is already properly limited.) This avoids very slow pauses in the fuzzer (that sometimes OOM).
* [Strings] Implement string.measure_wtf16 in interpreter (#6535)Alon Zakai2024-04-241-1/+1
|
* [Strings] Fuzz and interpret all relevant StringNew methods (#6526)Alon Zakai2024-04-231-0/+11
| | | | This adds fuzzing for string.new_wtf16_array and string.from_code_point. The latter was also missing interpreter support, which this adds.
* Handle return calls correctlyThomas Lively2024-04-081-65/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a combined commit covering multiple PRs fixing the handling of return calls in different areas. The PRs are all landed as a single commit to ensure internal consistency and avoid problems with bisection. Original PR descriptions follow: * Fix inlining of `return_call*` (#6448) Previously we transformed return calls in inlined function bodies into normal calls followed by branches out to the caller code. Similarly, when inlining a `return_call` callsite, we simply added a `return` after the body inlined at the callsite. These transformations would have been correct if the semantics of return calls were to call and then return, but they are not correct for the actual semantics of returning and then calling. The previous implementation is observably incorrect for return calls inside try blocks, where the previous implementation would run the inlined body within the try block, but the proper semantics would be to run the inlined body outside the try block. Fix the problem by transforming inlined return calls to branches followed by calls rather than as calls followed by branches. For the case of inlined return call callsites, insert branches out of the original body of the caller and inline the body of the callee as a sibling of the original caller body. For the other case of return calls appearing in inlined bodies, translate the return calls to branches out to calls inserted as siblings of the original inlined body. In both cases, it would have been convenient to use multivalue block return to send call parameters along the branches to the calls, but unfortunately in our IR that would have required tuple-typed scratch locals to unpack the tuple of operands at the call sites. It is simpler to just use locals to propagate the operands in the first place. * Fix interpretation of `return_call*` (#6451) We previously interpreted return calls as calls followed by returns, but that is not correct both because it grows the size of the execution stack and because it runs the called functions in the wrong context, which can be observable in the case of exception handling. Update the interpreter to handle return calls correctly by adding a new `RETURN_CALL_FLOW` that behaves like a return, but carries the arguments and reference to the return-callee rather than normal return values. `callFunctionInternal` is updated to intercept this flow and call return-called functions in a loop until a function returns with some other kind of flow. Pull in the upstream spec tests return_call.wast, return_call_indirect.wast, and return_call_ref.wast with light editing so that we parse and validate them successfully. * Handle return calls in wasm-ctor-eval (#6464) When an evaluated export ends in a return call, continue evaluating the return-called function. This requires propagating the parameters, handling the case that the return-called function might be an import, and fixing up local indices in case the final function has different parameters than the original function. * Update effects.h to handle return calls correctly (#6470) As far as their surrounding code is concerned return calls are no different from normal returns. It's only from a caller's perspective that a function containing a return call also has the effects of the return-callee. To model this more precisely in EffectAnalyzer, stash the throw effect of return-callees on the side and only merge it in at the end when analyzing the effects of a full function body.
* [Strings] string.new_wtf16_array should trap if the end index is less than ↵Alon Zakai2024-04-011-1/+2
| | | | the start (#6459)
* Report timeout in interpretation of AtomicWait (#6452)Thomas Lively2024-03-291-1/+1
| | | | | | | To avoid slow-running fuzz cases, we report a host limit when interpreting atomic.wait with any non-zero timeout. However, in the allowed case where the timeout is zero, we were incorrectly interpreting the wait as returning 0, meaning that it was woken up, instead of 2, meaning that the timeout expired. Fix it to return 2.
* Remove the TRAVERSE_CALLS option in the ConstantExpressionRunner (#6449)Thomas Lively2024-03-291-33/+0
| | | | | | | | The implementation of calls with this option was incorrect because it cleared the locals before evaluating the call arguments. The likely explanation for why this was never noticed is that there are no users of this option, especially since it is exposed in the C and JS APIs but not used internally. Rather than try to fix the implementation, just remove the option.
* StringNew: Trap on OOB start index (#6438)Alon Zakai2024-03-251-1/+1
|
* [Strings] Represent string values as WTF-16 internally (#6418)Thomas Lively2024-03-221-49/+4
| | | | | | | | | | | | | | | | WTF-16, i.e. arbitrary sequences of 16-bit values, is the encoding of Java and JavaScript strings, and using the same encoding makes the interpretation of string operations trivial, even when accounting for non-ascii characters. Specifically, use little-endian WTF-16. Re-encode string constants from WTF-8 to WTF-16 in the parsers, then back to WTF-8 in the writers. Update the constructor for string `Literal`s to interpret the string as WTF-16 and store a sequence of WTF-16 code units, i.e. 16-bit integers. Update `Builder::makeConstantExpression` accordingly to convert from the new `Literal` string representation back to a WTF-16 string. Update the interpreter to remove the logic for detecting non-ascii characters and bailing out. The naive implementations of all the string operations are correct now that our string encoding matches the JS string encoding.
* [Strings] Handle overflow in string.encode_wtf16_array (#6422)Alon Zakai2024-03-221-2/+5
|
* [Strings] Fix StringSlice end computation (#6414)Alon Zakai2024-03-211-3/+2
| | | | | Like JS string slicing, if the end index is out of bounds that is fine, we clamp to the end. This also matches the behavior in V8 and the spec.
* [Strings] Avoid mishandling unicode in StringConcat (#6411)Roberto Lublinerman2024-03-191-0/+5
|
* Atomics: Handle timeouts in waits in the (single-threaded) interpreter (#6408)Alon Zakai2024-03-191-3/+9
| | | | | | | | | The interpreter does not run multiple threads, and it was returning 0 from atomic.wait, which means it was woken up. But it is more correct for it to return 2, which means it timed out - which is actually the case, as no other thread exists that can wake it up. However, even that is not good for fuzzing as the timeout may be infinite or large, so just emit a host limit error on any timeout for now, until we actually implement threads.
* [Strings] Implement stringview_wtf16.slice (#6404)Alon Zakai2024-03-191-4/+49
|
* Typed continuations: suspend instructions (#6393)Frank Emrich2024-03-191-0/+2
| | | | | | | | | | | | | | | | | | | | | This PR is part of a series that adds basic support for the [typed continuations/wasmfx proposal](https://github.com/wasmfx/specfx). This particular PR adds support for the `suspend` instruction for suspending with a given tag, documented [here](https://github.com/wasmfx/specfx/blob/main/proposals/continuations/Overview.md#instructions). These instructions are of the form `(suspend $tag)`. Assuming that `$tag` is defined with _n_ `param` types `t_1` to `t_n`, the instruction consumes _n_ arguments of types `t_1` to `t_n`. Its result type is the same as the `result` type of the tag. Thus, the folded textual representation looks like `(suspend $tag arg1 ... argn)`. Support for the instruction is implemented in both the old and the new wat parser. Note that this PR does not implement validation of the new instruction. This PR also fixes finalization of `cont.new`, `cont.bind` and `resume` nodes in those cases where any of their children are unreachable.
* [Strings] Avoid mishandling unicode in interpreter (#6405)Thomas Lively2024-03-181-0/+34
| | | | | | | Our interpreter implementations of `stringview_wtf16.length`, `stringview_wtf16.get_codeunit`, and `string.encode_wtf16_array` are not unicode-aware, so they were previously incorrect in the face of multi-byte code units. As a fix, bail out of the interpretation if there is a non-ascii code point that would make our naive implementation incorrect.
* [Strings] Implement string.concat in the interpreter (#6403)Roberto Lublinerman2024-03-151-1/+30
|
* [Strings] Implement string.encode_wtf16_array (#6402)Alon Zakai2024-03-141-1/+37
|
* [Strings] Fix precomputing of StringEq (#6401)Alon Zakai2024-03-141-35/+20
| | | | | | | | We incorrectly overrode the string operations in the interpreter's subclasses. But string operations can be implemented in the topmost class there (as they depend on no module state), so just implement them there, once, in a proper way. This fixes StringEq by removing its override, and moves the others to the right place.
* Typed continuations: cont.bind instructions (#6365)Frank Emrich2024-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This PR is part of a series that adds basic support for the [typed continuations/wasmfx proposal](https://github.com/wasmfx/specfx). This particular PR adds support for the `cont.bind` instruction for partially applying continuations, documented [here](https://github.com/wasmfx/specfx/blob/main/proposals/continuations/Overview.md#instructions). In short, these instructions are of the form `(cont.bind $ct_before $ct_after)` where `$ct_before` and `$ct_after` are related continuation types. They must only differ in the number of arguments, where `$ct_before` has _n_ additional parameters as compared to `$ct_after`, for some _n_ ≥ 0. The idea is that `(cont.bind $ct_before $ct_after)` then takes a reference to a continuation of type `$ct_before` as well as _n_ operands and returns a (reference to a) continuation of type `$ct_after`. Thus, the folded textual representation looks like `(cont.bind $ct_before $ct_after arg1 ... argn c)`. Support for the instruction is implemented in both the old and the new wat parser. Note that this PR does not implement validation of the new instruction.
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-06 00:18:54 +0000