summaryrefslogtreecommitdiff
path: root/src/binaryen-c.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Typed continuations: nocont and cont basic heap types (#6468)Frank Emrich2024-04-041-0/+4
| | | | | | | | This PR is part of a series that adds basic support for the typed continuations/wasmfx proposal. This particular PR adds cont and nocont as top and bottom types for continuation types, completely analogous to func and nofunc for function types (also: exn and noexn).
* Remove the TRAVERSE_CALLS option in the ConstantExpressionRunner (#6449)Thomas Lively2024-03-291-4/+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.
* [Strings] Represent string values as WTF-16 internally (#6418)Thomas Lively2024-03-221-1/+7
| | | | | | | | | | | | | | | | 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.
* Expose features option in C API binary reading (#6380)Surma2024-03-071-3/+8
| | | | This allows reading a module that requires a particular feature set. The old API assumed only MVP features.
* C API: Support adding data segments individually (#6346)Lingming Zhang2024-02-281-0/+19
| | | Fixes #6314.
* C API: Use segment names (#6254)ericvergnaud2024-02-011-26/+30
| | | | | | | | | Move from segment indexes to names. This is a breaking change to make the API more capable and consistent. An effort has been made to reduce the burden on C API users where possible (specifically, you can avoid providing names and let Binaryen make them for you, which will basically be numbers that match the indexes from before). Fixes #6247
* C API: Add BinaryenArrayNewData (#6236)ericvergnaud2024-01-251-0/+11
|
* C API: Add BinaryenFunctionAppendVar (#6213)KinderGartenKiller2024-01-171-0/+4
|
* [EH] Add exnref type back (#6149)Heejin Ahn2023-12-081-0/+4
| | | | | | | | | | | | | At the Oct hybrid CG meeting, we decided to add back `exnref`, which was removed in 2020: https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-10.md The new version of the proposal reflected in the explainer: https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md While adding support for `exnref` in the current codebase which has all GC subtype hierarchies, I noticed we might need `noexn` heap type for the bottom type of `exn`. We don't have it now so I just set it to 0xff for the moment.
* C API: Add BinaryenTableGetType and BinaryenTableSetType (#6137)KinderGartenKiller2023-11-301-0/+6
| | | Fixes #6136
* Replace I31New with RefI31 everywhere (#5930)Thomas Lively2023-09-131-9/+9
| | | | | | | | Globally replace the source string "I31New" with "RefI31" in preparation for renaming the instruction from "i31.new" to "ref.i31", as implemented in the spec in https://github.com/WebAssembly/gc/pull/422. This would be NFC, except that it also changes the string in the external-facing C APIs. A follow-up PR will make the corresponding behavioral change.
* Make final types the default (#5918)Thomas Lively2023-09-091-0/+3
| | | | | | | | | | | | | Match the spec and parse the shorthand binary and text formats as final and emit final types without supertypes using the shorthands as well. This is a potentially-breaking change, since the text and binary shorthands can no longer be used to define types that have subtypes. Also make TypeBuilder entries final by default to better match the spec and update the internal APIs to use the "open" terminology rather than "final" terminology. Future changes will update the text format to use the standard "sub open" rather than the current "sub final" keywords. The exception is the new wat parser, which supporst "sub open" as of this change, since it didn't support final types at all previously.
* Rename multimemory flag (#5890)Ashley Nelson2023-08-211-2/+2
| | | Renaming the multimemory flag in Binaryen to match its naming in LLVM.
* Remove legacy WasmGC instructions (#5861)Thomas Lively2023-08-091-2/+1
| | | | | Remove old, experimental instructions and type encodings that will not be shipped as part of WasmGC. Updating the encodings and text format to match the final spec is left as future work.
* C API: Add BinaryenAddFunctionWithHeapType which takes a heap type (#5829)Alon Zakai2023-07-211-9/+28
| | | | | | | | | | | This is necessary for WasmGC producers using the C API, so that they can set the heap type of functions. Otherwise the heap type is set structurally using params and results in the old API. The old API is kept for backwards compatibility and convenience (for the structural case, which is all code before WasmGC basically). Fixes #5826
* Rename WasmBinaryBuilder to WasmBinaryReader (NFC) (#5767)Heejin Ahn2023-06-131-1/+1
| | | | | | We have `WasmBinaryBuilder` that read binary into Binaryen IR and `WasmBinaryWriter` that writes Binaryen IR to binary. To me `WasmBinaryBuilder` sounds similar to `WasmBinaryWriter`, which builds binary. How about renaming it to `WasmBinaryReader`?
* [Strings] Adopt new instruction binary encoding (#5714)Jérôme Vouillon2023-05-121-2/+8
| | | | | | | | | | | See WebAssembly/stringref#46. This format is already adopted by V8: https://chromium-review.googlesource.com/c/v8/v8/+/3892695. The text format is left unchanged (see #5607 for a discussion on the subject). I have also added support for string.encode_lossy_utf8 and string.encode_lossy_utf8 array (by allowing the replace policy for Binaryen's string.encode_wtf8 instruction).
* Remove the ability to construct basic types in a TypeBuilder (#5678)Thomas Lively2023-04-191-13/+0
| | | | | | | | | | | This capability was originally introduced to support calculating LUBs in the equirecursive type system, but has not been needed for anything except tests since the equirecursive type system was removed. Since building basic heap types is no longer useful and was a source of significant complexity, remove the APIs that allowed it and the tests that used those APIs. Also remove test/example/type-builder.cpp, since a significant portion of it tested the removed APIs and the rest is already better tested in test/gtest/type-builder.cpp.
* Remove the nominal type system (#5672)Thomas Lively2023-04-171-15/+0
| | | | | And since the only type system left is the standard isorecursive type system, remove `TypeSystem` and its associated APIs entirely. Delete a few tests that only made sense under the isorecursive type system.
* Use Names instead of indices to identify segments (#5618)Thomas Lively2023-04-041-12/+13
| | | | | | | | | | All top-level Module elements are identified and referred to by Name, but for historical reasons element and data segments were referred to by index instead. Fix this inconsistency by using Names to refer to segments from expressions that use them. Also parse and print segment names like we do for other elements. The C API is partially converted to use names instead of indices, but there are still many functions that refer to data segments by index. Finishing the conversion can be done in the future once it becomes necessary.
* [NFC] Remove our bespoke `make_unique` implementation (#5613)Thomas Lively2023-03-311-6/+6
| | | | This code predates our adoption of C++14 and can now be removed in favor of `std::make_unique`, which should be more efficient.
* Support interpretation of extern.externalize and extern.internalize (#5576)Thomas Lively2023-03-161-1/+1
| | | | | | | To allow the external and internal reference values to be differentiated yet round-trippable, set the `Literal` type to externref on external references, but keep the gcData the same for both. The only exception is for i31 references, for which the externalized version gets a `gcData` that contains a copy of the original i31 literal.
* [NFC] Internally rename `ArrayInit` to `ArrayNewFixed` (#5526)Thomas Lively2023-02-281-33/+37
| | | | | | | | To match the standard instruction name, rename the expression class without changing any parsing or printing behavior. A follow-on PR will take care of the functional side of this change while keeping support for parsing the old name. This change will allow `ArrayInit` to be used as the expression class for the upcoming `array.init_data` and `array.init_elem` instructions.
* [C API] Add relaxed SIMD operations (#5482)dcode2023-02-071-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Exposes the constants **Unary** * BinaryenRelaxedTruncSVecF32x4ToVecI32x4 * BinaryenRelaxedTruncSVecF32x4ToVecI32x4 * BinaryenRelaxedTruncZeroSVecF64x2ToVecI32x4 * BinaryenRelaxedTruncZeroUVecF64x2ToVecI32x4 **Binary** * BinaryenRelaxedSwizzleVecI8x16 * BinaryenRelaxedMinVecF32x4 * BinaryenRelaxedMaxVecF32x4 * BinaryenRelaxedMinVecF64x2 * BinaryenRelaxedMaxVecF64x2 * BinaryenRelaxedQ15MulrSVecI16x8 * BinaryenDotI8x16I7x16SToVecI16x8 **SIMDTernary** * BinaryenRelaxedFmaVecF32x4 * BinaryenRelaxedFmsVecF32x4 * BinaryenRelaxedFmaVecF64x2 * BinaryenRelaxedFmsVecF64x2 * BinaryenLaneselectI8x16 * BinaryenLaneselectI16x8 * BinaryenLaneselectI32x4 * BinaryenLaneselectI64x2 * BinaryenDotI8x16I7x16AddSToVecI32x4 so the respective instructions can be produced and inspected with the C API.
* [C API] Add experimental StringNew and StringEq variants (#5471)dcode2023-02-011-5/+29
| | | | Adds APIs for string.from_code_point, string.new_utf8_try, string.new_utf8_array_try (#5459) and string.compare (#5453).
* [Strings] Add experimental StringNew variants (#5459)Alon Zakai2023-01-261-2/+6
| | | | | | string.from_code_point makes a string from an int code point. string.new_utf8*_try makes a utf8 string and returns null on a UTF8 encoding error rather than trap.
* [Strings] Add string.compare (#5453)Alon Zakai2023-01-251-1/+1
| | | See WebAssembly/stringref#58
* Fix segment fault in API BinaryenModuleParse (#5440) (#5441)Changqing Jing2023-01-201-1/+1
| | | | | | We cannot modify the input string safely. To avoid that, copy where needed. Fixes #5440
* [Wasm GC] Replace `HeapType::data` with `HeapType::struct_` (#5416)Thomas Lively2023-01-101-6/+6
| | | | | | `struct` has replaced `data` in the upstream spec, so update Binaryen's types to match. We had already supported `struct` as an alias for data, but now remove support for `data` entirely. Also remove instructions like `ref.is_data` that are deprecated and do not make sense without a `data` type.
* Represent ref.as_{func,data,i31} with RefCast (#5413)Thomas Lively2023-01-101-3/+0
| | | | | | | | | | | | | These operations are deprecated and directly representable as casts, so remove their opcodes in the internal IR and parse them as casts instead. For now, add logic to the printing and binary writing of RefCast to continue emitting the legacy instructions to minimize test changes. The few test changes necessary are because it is no longer valid to perform a ref.as_func on values outside the func type hierarchy now that ref.as_func is subject to the ref.cast validation rules. RefAsExternInternalize, RefAsExternExternalize, and RefAsNonNull are left unmodified. A future PR may remove RefAsNonNull as well, since it is also expressible with casts.
* Replace `RefIs` with `RefIsNull` (#5401)Thomas Lively2023-01-091-26/+11
| | | | | | | | | | | | | | | * Replace `RefIs` with `RefIsNull` The other `ref.is*` instructions are deprecated and expressible in terms of `ref.test`. Update binary and text parsing to parse those instructions as `RefTest` expressions. Also update the printing and emitting of `RefTest` expressions to emit the legacy instructions for now to minimize test changes and make this a mostly non-functional change. Since `ref.is_null` is the only `RefIs` instruction left, remove the `RefIsOp` field and rename the expression class to `RefIsNull`. The few test changes are due to the fact that `ref.is*` instructions are now subject to `ref.test` validation, and in particular it is no longer valid to perform a `ref.is_func` on a value outside of the `func` type hierarchy.
* Consolidate br_on* operations (#5399)Thomas Lively2023-01-061-6/+0
| | | | | | | | | | | | | | | | | | The `br_on{_non}_{data,i31,func}` operations are deprecated and directly representable in terms of the new `br_on_cast` and `br_on_cast_fail` instructions, so remove their dedicated IR opcodes in favor of representing them as casts. `br_on_null` and `br_on_non_null` cannot be consolidated the same way because their behavior is not directly representable in terms of `br_on_cast` and `br_on_cast_fail`; when the cast to null bottom type succeeds, the null check instructions implicitly drop the null value whereas the cast instructions would propagate it. Add special logic to the binary writer and printer to continue emitting the deprecated instructions for now. This will allow us to update the test suite in a separate future PR with no additional functional changes. Some tests are updated because the validator no longer allows passing non-func data to `br_on_func`. Doing so has not made sense since we separated the three reference type hierarchies.
* Support br_on_cast null (#5397)Thomas Lively2023-01-051-10/+8
| | | | | | | | | As well as br_on_cast_fail null. Unlike the existing br_on_cast* instructions, these new instructions treat the cast as succeeding when the input is a null. Update the internal representation of the cast type in `BrOn` expressions to be a `Type` rather than a `HeapType` so it will include nullability information. Also update and improve `RemoveUnusedBrs` to handle the new instructions correctly and optimize in more cases.
* Support `ref.test null` (#5368)Thomas Lively2022-12-211-8/+7
| | | This new variant of ref.test returns 1 if the input is null.
* Update RefCast representation to drop extra HeapType (#5350)Thomas Lively2022-12-201-16/+4
| | | | | | | | | The latest upstream version of ref.cast is parameterized with a target reference type, not just a heap type, because the nullability of the result is parameterizable. As a first step toward implementing these new, more flexible ref.cast instructions, change the internal representation of ref.cast to use the expression type as the cast target rather than storing a separate heap type field. For now require that the encoded semantics match the previously allowed semantics, though, so that none of the optimization passes need to be updated.
* Remove equirecursive typing (#5240)Thomas Lively2022-11-231-3/+0
| | | | Equirecursive is no longer standards track and its implementation is extremely complex. Remove it.
* Rename UserSection -> CustomSection. NFC (#5288)Sam Clegg2022-11-221-2/+2
| | | This reflects that naming used in the spec.
* [C API] Add APIs to inspect compound heap types (#5195)dcode2022-11-031-0/+56
| | | | | | | | | | | | | | | | | | | | | | Adds C APIs to inspect compound struct, array and signature heap types: Obtain field types, field packed types and field mutabilities of struct types: BinaryenStructTypeGetNumFields (to iterate) BinaryenStructTypeGetFieldType BinaryenStructTypeGetFieldPackedType BinaryenStructTypeIsFieldMutable Obtain element type, element packed type and element mutability of array types: BinaryenArrayTypeGetElementType BinaryenArrayTypeGetElementPackedType BinaryenArrayTypeIsElementMutable Obtain parameter and result types of signature types: BinaryenSignatureTypeGetParams BinaryenSignatureTypeGetResults
* [C API] Add essential heap type utilities (#5160)dcode2022-10-261-0/+15
| | | | | | | | | | Adds heap type utility to the C API: BinaryenHeapTypeIsBasic BinaryenHeapTypeIsSignature BinaryenHeapTypeIsStruct BinaryenHeapTypeIsArray BinaryenHeapTypeIsSubType
* [C API] Align I31ref and Dataref to be nullable (#5153)dcode2022-10-191-2/+2
| | | The C API still returned non nullable types for `dataref` (`ref data` instead of `ref null data`) and `i31ref` (`ref i31` instead of `ref null i31`). This PR aligns with the current state of the GC proposal, making them nullable when obtained via the C API.
* [C API] Add bottom heap types and array heap type (#5150)dcode2022-10-181-0/+22
| | | Adds `BinaryenHeapTypeNone`, `BinaryenHeapTypeNoext` and `BinaryenHeapTypeNofunc` to obtain the bottom heap types. Also adds `BinaryenHeapTypeIsBottom` to test whether a given heap type is a bottom type, and `BinaryenHeapTypeGetBottom` to obtain the respective bottom type given a heap type.
* 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`.
* Make `Name` a pointer, length pair (#5122)Thomas Lively2022-10-111-52/+52
| | | | | | | | | | | | | | | | | | | | | | | 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-81/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [C API] Make TypeBuilderSetSubType take a heap type (#5045)dcode2022-09-231-2/+2
| | | Fixes #5041
* [C-/JS-Api] Expose the multi memories feature (#4973)Max Graey2022-09-201-0/+3
| | | This finalizes the multi memories feature introduced in #4968.
* [C API] Add getters and setters for various GC/Strings expressions (#5037)dcode2022-09-141-0/+918
| | | Covers CallRef, RefTest, RefCast, BrOn, StructNew, StructGet, StructSet, ArrayNew, ArrayInit, ArrayGet, ArraySet, ArrayLen, ArrayCopy, StringNew, StringConst, StringMeasure, StringEncode, StringConcat, StringEq, StringAs, StringWTF8Advance, StringWTF16Get, StringIterNext, StringIterMove, StringSliceWTF, StringSliceIter.
* [C-/JS-API] Add new BinaryenMemoryIs64 API + add memory64 argument for ↵Max Graey2022-09-121-0/+13
| | | | BinaryenSetMemory (#4963)
* Remove typed-function-references feature (#5030)Thomas Lively2022-09-091-3/+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.
* Add remaining GC and string instructions to C API (#4998)dcode2022-08-311-14/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds C-API bindings for the following expression classes: RefTest RefCast BrOn with operations BrOnNull, BrOnNonNull, BrOnCast, BrOnCastFail, BrOnFunc, BrOnNonFunc, BrOnData, BrOnNonData, BrOnI31, BrOnNonI31 StructNew with operations StringNewUTF8, StringNewWTF8, StringNewReplace, StringNewWTF16, StringNewUTF8Array, StringNewWTF8Array, StringNewReplaceArray, StringNewWTF16Array StructGet StructSet ArrayNew ArrayInit ArrayGet ArraySet ArrayLen ArrayCopy StringNew StringConst StringMeasure with operations StringMeasureUTF8, StringMeasureWTF8, StringMeasureWTF16, StringMeasureIsUSV, StringMeasureWTF16View StringEncode with operations StringEncodeUTF8, StringEncodeWTF8, StringEncodeWTF16, StringEncodeUTF8Array, StringEncodeWTF8Array, StringEncodeWTF16Array StringConcat StringEq StringAs with operations StringAsWTF8, StringAsWTF16, StringAsIter StringWTF8Advance StringWTF16Get StringIterNext StringIterMove with operations StringIterMoveAdvance, StringIterMoveRewind StringSliceWTF with operations StringSliceWTF8, StringSliceWTF16 StringSliceIter
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-07 20:34:32 +0000