summaryrefslogtreecommitdiff
path: root/src/wasm-binary.h
Commit message (Collapse)AuthorAgeFilesLines
* Parse and emit `array.len` without a type annotation (#5151)Thomas Lively2022-10-181-1/+2
| | | Test that we can still parse the old annotated form as well.
* Implement `array` basic heap type (#5148)Thomas Lively2022-10-181-0/+2
| | | | | | | | | `array` is the supertype of all defined array types and for now is a subtype of `data`. (Once `data` becomes `struct` this will no longer be true.) Update the binary and text parsing of `array.len` to ignore the obsolete type annotation and update the binary emitting to emit a zero in place of the old type annotation and the text printing to print an arbitrary heap type for the annotation. A follow-on PR will add support for the newer unannotated version of `array.len`.
* Support null characters in string.const expressions (#5123)Thomas Lively2022-10-111-1/+1
| | | | Remove an obsolete error about null characters and test both binary and text round tripping of a string constant containing an escaped zero byte.
* Make `Name` a pointer, length pair (#5122)Thomas Lively2022-10-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | With the goal of supporting null characters (i.e. zero bytes) in strings. Rewrite the underlying interned `IString` to store a `std::string_view` rather than a `const char*`, reduce the number of map lookups necessary to intern a string, and present a more immutable interface. Most importantly, replace the `c_str()` method that returned a `const char*` with a `toString()` method that returns a `std::string`. This new method can correctly handle strings containing null characters. A `const char*` can still be had by calling `data()` on the `std::string_view`, although this usage should be discouraged. This change is NFC in spirit, although not in practice. It does not intend to support any particular new functionality, but it is probably now possible to use strings containing null characters in at least some cases. At least one parser bug is also incidentally fixed. Follow-on PRs will explicitly support and test strings containing nulls for particular use cases. The C API still uses `const char*` to represent strings. As strings containing nulls become better supported by the rest of Binaryen, this will no longer be sufficient. Updating the C and JS APIs to use pointer, length pairs is left as future work.
* Implement bottom heap types (#5115)Thomas Lively2022-10-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | These types, `none`, `nofunc`, and `noextern` are uninhabited, so references to them can only possibly be null. To simplify the IR and increase type precision, introduce new invariants that all `ref.null` instructions must be typed with one of these new bottom types and that `Literals` have a bottom type iff they represent null values. These new invariants requires several additional changes. First, it is now possible that the `ref` or `target` child of a `StructGet`, `StructSet`, `ArrayGet`, `ArraySet`, or `CallRef` instruction has a bottom reference type, so it is not possible to determine what heap type annotation to emit in the binary or text formats. (The bottom types are not valid type annotations since they do not have indices in the type section.) To fix that problem, update the printer and binary emitter to emit unreachables instead of the instruction with undetermined type annotation. This is a valid transformation because the only possible value that could flow into those instructions in that case is null, and all of those instructions trap on nulls. That fix uncovered a latent bug in the binary parser in which new unreachables within unreachable code were handled incorrectly. This bug was not previously found by the fuzzer because we generally stop emitting code once we encounter an instruction with type `unreachable`. Now, however, it is possible to emit an `unreachable` for instructions that do not have type `unreachable` (but are known to trap at runtime), so we will continue emitting code. See the new test/lit/parse-double-unreachable.wast for details. Update other miscellaneous code that creates `RefNull` expressions and null `Literals` to maintain the new invariants as well.
* Warn on too many parameters for Web VMs (#5119)Alon Zakai2022-10-061-1/+2
| | | Fixes emscripten-core/emscripten#17988
* Emit call_ref with a type annotation (#5079)Thomas Lively2022-09-231-1/+2
| | | | | | | Emit call_ref instructions with type annotations and a temporary opcode. Also implement support for parsing optional type annotations on call_ref in the text and binary formats. This is part of a multi-part graceful update to switch Binaryen and all of its users over to using the type-annotated version of call_ref without there being any breakage.
* Add a type annotation to return_call_ref (#5068)Thomas Lively2022-09-221-1/+2
| | | | | | The GC spec has been updated to have heap type annotations on call_ref and return_call_ref. To avoid breaking users, we will have a graceful, multi-step upgrade to the annotated version of call_ref, but since return_call_ref has no users yet, update it in a single step.
* Remove typed-function-references feature (#5030)Thomas Lively2022-09-091-1/+0
| | | | | | | | | | | | | | | | In practice typed function references will not ship before GC and is not independently useful, so it's not necessary to have a separate feature for it. Roll the functionality previously enabled by --enable-typed-function-references into --enable-gc instead. This also avoids a problem with the ongoing implementation of the new GC bottom heap types. That change will make all ref.null instructions in Binaryen IR refer to one of the bottom heap types. But since those bottom types are introduced in GC, it's not valid to emit them in binaries unless unless GC is enabled. The fix if only reference types is enabled is to emit (ref.null func) instead of (ref.null nofunc), but that doesn't always work if typed function references are enabled because a function type more specific than func may be required. Getting rid of typed function references as a separate feature makes this a nonissue.
* [NFC] Simplify binary reading logic for data segments (#4990)Alon Zakai2022-08-311-3/+0
| | | Similar to #4969 but for data segments.
* [NFC] Simplify binary reading logic for element segments (#4989)Alon Zakai2022-08-291-4/+0
| | | Similar to #4969 but for element segments.
* Implement `extern.externalize` and `extern.internalize` (#4975)Thomas Lively2022-08-291-0/+2
| | | | These new GC instructions infallibly convert between `extern` and `any` references now that those types are not in the same hierarchy.
* [NFC] Simplify binary reading logic for memories (#4987)Alon Zakai2022-08-291-6/+0
| | | Similar to #4969 but for memories.
* [NFC] Simplify binary reading logic for globals (#4980)Alon Zakai2022-08-291-5/+0
| | | Similar to #4969 but for globals.
* [NFC] Simplify binary reading logic for tables (#4974)Alon Zakai2022-08-261-5/+0
| | | Similar to #4969 but for tables.
* Add support for Tag names in the Names section (#4970)Alon Zakai2022-08-261-0/+4
|
* [NFC] Simplify binary reading logic for functions (#4969)Alon Zakai2022-08-261-5/+0
| | | | | | | We do a call to updateMaps() at the end of processNames anyhow, and so we may as well call addFunction immediately (and the names will get fixed up in that updateMaps later). The old code for some reason did that for function imports, but not normal functions. It also stored them separately in temporary storage for some unclear reason...
* Adding Multi-Memories Wasm Feature (#4968)Ashley Nelson2022-08-251-0/+1
| | | Adding multi-memories to the the list of wasm-features.
* Fix Memory64 binary parsing after #4811 (#4933)Alon Zakai2022-08-181-0/+3
| | | | Due to missing test coverage, we missed in #4811 that some memory operations needed to get make64() called on them.
* Restore the `extern` heap type (#4898)Thomas Lively2022-08-171-3/+6
| | | | | | | The GC proposal has split `any` and `extern` back into two separate types, so reintroduce `HeapType::ext` to represent `extern`. Before it was originally removed in #4633, externref was a subtype of anyref, but now it is not. Now that we have separate heaptype type hierarchies, make `HeapType::getLeastUpperBound` fallible as well.
* Mutli-Memories Support in IR (#4811)Ashley Nelson2022-08-171-3/+16
| | | | | | | This PR removes the single memory restriction in IR, adding support for a single module to reference multiple memories. To support this change, a new memory name field was added to 13 memory instructions in order to identify the memory for the instruction. It is a goal of this PR to maintain backwards compatibility with existing text and binary wasm modules, so memory indexes remain optional for memory instructions. Similarly, the JS API makes assumptions about which memory is intended when only one memory is present in the module. Another goal of this PR is that existing tests behavior be unaffected. That said, tests must now explicitly define a memory before invoking memory instructions or exporting a memory, and memory names are now printed for each memory instruction in the text format. There remain quite a few places where a hardcoded reference to the first memory persist (memory flattening, for example, will return early if more than one memory is present in the module). Many of these call-sites, particularly within passes, will require us to rethink how the optimization works in a multi-memories world. Other call-sites may necessitate more invasive code restructuring to fully convert away from relying on a globally available, single memory pointer.
* Remove RTTs (#4848)Thomas Lively2022-08-051-19/+1
| | | | | | | RTTs were removed from the GC spec and if they are added back in in the future, they will be heap types rather than value types as in our implementation. Updating our implementation to have RTTs be heap types would have been more work than deleting them for questionable benefit since we don't know how long it will be before they are specced again.
* Remove support for parsing `let` (#4864)Thomas Lively2022-08-031-26/+0
| | | | | It has been removed from the typed function references proposal, so we no longer need to support it. Maintaining the test for `let` was difficult because Binaryen could not emit either text or binary that actually used it.
* Changing ref maps in wasm-binary to use a value of a vector of Name* (#4830)Ashley Nelson2022-07-261-3/+3
| | | | | | | | | | | * Changing ref maps in wasm-binary to use a value of a vector of Name* * clang-format * Update src/wasm/wasm-binary.cpp Co-authored-by: Thomas Lively <7121787+tlively@users.noreply.github.com> Co-authored-by: Thomas Lively <7121787+tlively@users.noreply.github.com>
* [Strings] GC variants for string.encode (#4817)Alon Zakai2022-07-211-0/+2
|
* [Strings] Add string.new GC variants (#4813)Alon Zakai2022-07-191-0/+2
|
* [Strings] stringview_wtf16.length (#4809)Alon Zakai2022-07-181-0/+1
| | | | This measures the length of a view, so it seems simplest to make it a sub-operation of the existing measure instruction.
* [Strings] stringview_*.slice (#4805)Alon Zakai2022-07-151-0/+5
| | | | | | | Unfortunately one slice is the same as python [start:end], using 2 params, and the other slice is one param, [CURR:CURR+num] (where CURR is implied by the current state in the iter). So we can't use a single class here. Perhaps a different name would be good, like slice vs substring (like JS does), but I picked names to match the current spec.
* [Strings] stringview access operations (#4798)Alon Zakai2022-07-131-0/+9
|
* [Strings] string.as (#4797)Alon Zakai2022-07-121-0/+4
|
* [Strings] string.is_usv_sequence (#4783)Alon Zakai2022-07-081-0/+1
| | | | | | | This implements it as a StringMeasure opcode. They do have the same number of operands, same trapping behavior, and same return type. They both get a string and do some inspection of it to return an i32. Perhaps the name could be StringInspect or something like that, rather than StringMeasure..? But I think for now this might be good enough, and the spec may change anyhow later.
* [Strings] string.eq (#4781)Alon Zakai2022-07-081-0/+2
|
* [Strings] string.concat (#4777)Alon Zakai2022-07-081-0/+2
|
* [Strings] string.encode (#4776)Alon Zakai2022-07-071-0/+3
|
* [Strings] string.measure (#4775)Alon Zakai2022-07-071-1/+4
|
* [Strings] Add string.const (#4768)Alon Zakai2022-07-061-1/+13
| | | | | This is more work than a typical instruction because it also adds a new section: all the (string.const "foo") strings are put in a new "strings" section in the binary, and the instructions refer to them by index.
* [Strings] Add feature flag for Strings proposal (#4766)Alon Zakai2022-06-301-0/+1
|
* [Strings] Add string.new* instructions (#4761)Alon Zakai2022-06-291-1/+10
| | | | | | This is the first instruction from the Strings proposal. This includes everything but interpreter support.
* [Strings] Add string proposal types (#4755)Alon Zakai2022-06-291-7/+19
| | | | | | | | This starts to implement the Wasm Strings proposal https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md This just adds the types.
* First class Data Segments (#4733)Ashley Nelson2022-06-211-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Updating wasm.h/cpp for DataSegments * Updating wasm-binary.h/cpp for DataSegments * Removed link from Memory to DataSegments and updated module-utils, Metrics and wasm-traversal * checking isPassive when copying data segments to know whether to construct the data segment with an offset or not * Removing memory member var from DataSegment class as there is only one memory rn. Updated wasm-validator.cpp * Updated wasm-interpreter * First look at updating Passes * Updated wasm-s-parser * Updated files in src/ir * Updating tools files * Last pass on src files before building * added visitDataSegment * Fixing build errors * Data segments need a name * fixing var name * ran clang-format * Ensuring a name on DataSegment * Ensuring more datasegments have names * Adding explicit name support * Fix fuzzing name * Outputting data name in wasm binary only if explicit * Checking temp dataSegments vector to validateBinary because it's the one with the segments before we processNames * Pass on when data segment names are explicitly set * Ran auto_update_tests.py and check.py, success all around * Removed an errant semi-colon and corrected a counter. Everything still passes * Linting * Fixing processing memory names after parsed from binary * Updating the test from the last fix * Correcting error comment * Impl kripken@ comments * Impl tlively@ comments * Updated tests that remove data print when == 0 * Ran clang format * Impl tlively@ comments * Ran clang-format
* Update relaxed SIMD instructionsThomas Lively2022-06-071-37/+35
| | | | | Update the opcodes for all relaxed SIMD instructions and remove the unsigned dot product instructions that are no longer in the proposal.
* Add ref.cast_nop_static (#4656)Thomas Lively2022-05-111-0/+1
| | | | | | This unsafe experimental instruction is semantically equivalent to ref.cast_static, but V8 will unsafely turn it into a nop. This is meant to help us measure cast overhead more precisely than we can by globally turning all casts into nops.
* Parse the prototype nominal binary format (#4644)Thomas Lively2022-05-041-0/+4
| | | | | | In f124a11ca3 we removed support for the prototype nominal binary format entirely, but that means that we can no longer parse older binary modules that used that format. Fix this regression by restoring the ability to parse the prototype binary format.
* Remove externref (#4633)Thomas Lively2022-05-041-10/+7
| | | | | | Remove `Type::externref` and `HeapType::ext` and replace them with uses of anyref and any, respectively, now that we have unified these types in the GC proposal. For backwards compatibility, continue to parse `extern` and `externref` and maintain their relevant C API functions.
* Update the type section binary format (#4625)Thomas Lively2022-05-021-7/+5
| | | | | | | | | | Print subtype declarations using the standards-track format with a vector of supertypes followed by a normal type declaration rather than our interim nominal format that used alternative versions of the func, struct, and array forms. Desugar the nominal format to additionally emit all the types into a single large recursion group. Currently V8 is performing this desugaring, but after this change and a future change that fixes the order of nominal types to ensure supertypes precede subtypes, it will no longer need to.
* Implement relaxed SIMD dot product instructions (#4586)Thomas Lively2022-04-111-0/+4
| | | As proposed in https://github.com/WebAssembly/relaxed-simd/issues/52.
* Implement i16x8.relaxed_q15mulr_s (#4583)Thomas Lively2022-04-071-1/+2
| | | As proposed in https://github.com/WebAssembly/relaxed-simd/issues/40.
* Add support for extended-const proposal (#4529)Sam Clegg2022-03-191-0/+1
| | | See https://github.com/WebAssembly/extended-const
* Isorecursive binary format (#4494)Thomas Lively2022-02-031-0/+2
| | | | | | | | | | | Write and parse recursion groups in binary type sections. Unlike in the text format, where we ignore recursion groups when not using isorecursive types, do not allow parsing binary recursion group when using other type systems. Doing so would produce incorrect results because recursions groups only count as single entries in the type system vector so we dynamically grow the TypeBuilder when we encounter them. That would change the mapping of later indices to types, and would change the meaning of previous type definitions that use those later indices. This is not a problem in the isorecursive system because in that system type definitions are not allowed to use later indices.
* Refactor ModuleUtils::collectHeapTypes (#4455)Thomas Lively2022-01-141-2/+1
| | | | | Update the API to make both the type indices and optimized sorting optional. It will become more important to avoid unnecessary sorting once isorecursive types have been implemented because they will make the sorting more complicated.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-29 11:52:09 +0000