summaryrefslogtreecommitdiff
path: root/test/example
Commit message (Collapse)AuthorAgeFilesLines
* Add standard versions of WasmGC casts (#5331)Thomas Lively2022-12-071-2/+2
| | | | | | | We previously supported only the non-standard cast instructions introduced when we were experimenting with nominal types. Parse the names and opcodes of their standard counterparts and switch to emitting the standard names and opcodes. Port all of the tests to use the standard instructions, but add additional tests showing that the non-standard versions are still parsed correctly.
* Remove equirecursive typing (#5240)Thomas Lively2022-11-235-108/+105
| | | | Equirecursive is no longer standards track and its implementation is extremely complex. Remove it.
* Change the default type system to isorecursive (#5239)Thomas Lively2022-11-236-394/+213
| | | | | | | | | | This makes Binaryen's default type system match the WasmGC spec. Update the way type definitions without supertypes are printed to reduce the output diff for MVP tests that do not involve WasmGC. Also port some type-builder.cpp tests from test/example to test/gtest since they needed to be rewritten to work with isorecursive type anyway. A follow-on PR will remove equirecursive types completely.
* Fix SmallSet ordering (#5218)Alon Zakai2022-11-041-0/+60
| | | We did not preserve the ordering of the fixed-size storage there.
* [C API] Add APIs to inspect compound heap types (#5195)dcode2022-11-032-3/+33
| | | | | | | | | | | | | | | | | | | | | | 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-21/+54
| | | | | | | | | | Adds heap type utility to the C API: BinaryenHeapTypeIsBasic BinaryenHeapTypeIsSignature BinaryenHeapTypeIsStruct BinaryenHeapTypeIsArray BinaryenHeapTypeIsSubType
* [C API] Add bottom heap types and array heap type (#5150)dcode2022-10-182-0/+42
| | | 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.
* Parse and emit `array.len` without a type annotation (#5151)Thomas Lively2022-10-181-1/+1
| | | Test that we can still parse the old annotated form as well.
* Implement `array` basic heap type (#5148)Thomas Lively2022-10-181-4/+4
| | | | | | | | | `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`.
* Implement bottom heap types (#5115)Thomas Lively2022-10-075-56/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | Fixes #5041
* [C-/JS-API] Add new BinaryenMemoryIs64 API + add memory64 argument for ↵Max Graey2022-09-1212-9/+15
| | | | BinaryenSetMemory (#4963)
* Remove typed-function-references feature (#5030)Thomas Lively2022-09-092-7/+4
| | | | | | | | | | | | | | | | 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-312-3/+610
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix SmallVector's resize() method (#4979)Alon Zakai2022-08-291-0/+35
| | | | A resize from a large amount to a small amount would sometimes not clear the flexible storage, if we used it before but not after.
* Adding Multi-Memories Wasm Feature (#4968)Ashley Nelson2022-08-251-1/+1
| | | Adding multi-memories to the the list of wasm-features.
* Fix multi-memory + C API for MemoryGrow and MemorySize (#4953)Alon Zakai2022-08-231-2/+2
| | | | | | | | | | | | | | | | Those instructions need to know if the memory is 64-bit or not. We looked that up on the module globally, which is convenient, but in the C API this was actually a breaking change, it turns out. To keep things working, provide that information when creating a MemoryGrow or MemorySize, as another parameter in the C API. In the C++ API (wasm-builder), support both modes, and default to the automatic lookup. We already require a bunch of other explicit info when creating expressions, like making a Call requires the return type (we don't look it up globally), and even a LocalGet requires the local type (we don't look it up on the function), so this is consistent with those. Fixes #4946
* Separate `func` into a separate type hierarchy (#4955)Thomas Lively2022-08-223-32/+32
| | | | | Just like `extern` is no longer a subtype of `any` in the new GC type system, `func` is no longer a subtype of `any`, either. Make that change in our type system implementation and update tests and fuzzers accordingly.
* Avoid emitting a block in the binary format when it has no name (#4912)Alon Zakai2022-08-181-13/+6
| | | | | | | | | | We already did this if the block was a child of a control flow structure, which is the common case (see the new added comment around that code, which clarifies why). This does the same for all other blocks. This is simple to do and a minor optimization, but the main benefit from this is just to make our handling of blocks uniform: after this, we never emit a block with no name. This will make 1a non- nullable locals easier to handle (since they will be able to assume that property; and not emitting such blocks avoids some work to handle non-nullable locals in them).
* Restore the `extern` heap type (#4898)Thomas Lively2022-08-172-12/+14
| | | | | | | 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-1712-500/+668
| | | | | | | 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-055-120/+6
| | | | | | | 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.
* [C-API] Add type builder C-API (#4803)dcode2022-08-042-0/+193
| | | Introduces the necessary APIs to use the type builder from C. Enables construction of compound heap types (arrays, structs and signatures) that may be recursive, including assigning concrete names to the built types and, in case of structs, their fields.
* [C/JS API] Add string reference types (#4810)dcode2022-07-272-0/+28
|
* [Wasm GC] Properly represent nulls in i31 (#4819)Alon Zakai2022-07-251-1/+1
| | | | | The encoding here is simple: we store i31 values in the literal.i32 field. The top bit says if a value exists, which means literal.i32 == 0 is the same as null.
* [C API] Fix printf-related warnings when compiling C tests (NFC) (#4821)dcode2022-07-252-15/+15
|
* [Test] Refactor C API kitchen sink test's Memory usage (#4815)Alon Zakai2022-07-212-19/+19
|
* Remove basic reference types (#4802)Thomas Lively2022-07-207-110/+118
| | | | | | | | | Basic reference types like `Type::funcref`, `Type::anyref`, etc. made it easy to accidentally forget to handle reference types with the same basic HeapTypes but the opposite nullability. In principle there is nothing special about the types with shorthands except in the binary and text formats. Removing these shorthands from the internal type representation by removing all basic reference types makes some code more complicated locally, but simplifies code globally and encourages properly handling both nullable and non-nullable reference types.
* [C-API] Add utility to go between types and heap types (#4792)dcode2022-07-141-0/+9
|
* [C-API] Unify logging in c-api-kitchen-sink test (#4800)dcode2022-07-132-34/+34
|
* [C-API] Add type system C-API (#4790)dcode2022-07-132-0/+19
|
* [C-API] Add packed type constants for use with GC types (#4791)dcode2022-07-122-0/+10
|
* [Strings] Add feature flag for Strings proposal (#4766)Alon Zakai2022-06-301-1/+1
|
* Add SubTypes::getAllSubTypes variant which includes the type itself (#4649)Alon Zakai2022-05-131-0/+1
| | | | This also includes the type itself in the returned vector. This will be useful in a future PR.
* Remove externref (#4633)Thomas Lively2022-05-047-46/+24
| | | | | | 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.
* Lift the restriction in liveness-traversal.h that supported max 65535 locals ↵juj2022-04-282-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in a function. (#4567) * Lift the restriction in liveness-traversal.h that supported max 65535 locals in a function. * Lint * Fix typo * Fix static * Lint * Lint * Lint * Add needed canRun function * lint * Use either a sparse or a dense matrix for tracking liveness copies, depending on the locals count. * Lint * Fix lint * Lint * Implement sparse_square_matrix class and use that as a backing. * Lint * Lint * Lint #includes * Lint * Lint includes * Remove unnecessary code * Fix canonical accesses to copies matrix * Lint * Add missing variable update * Remove canRun() function * Address review * Update expected test results * Update test name * Add asserts to sparse_square_matrix set and get functions that they are not out of bound. * Lint includes * Update test expectation * Use .clear() + .resize() to reset totalCopies vector
* [SIMD] Make swizzle's opcode name consistent (NFC) (#4585)Heejin Ahn2022-04-091-1/+1
| | | | Other opcode ends with `Inxm` or `Fnxm` (where n and m are integers), while `i8x16.swizzle`'s opcode name doesn't have an `I` in there.
* [NFC] Refactor Feature::All to match FeatureSet.setAll() (#4557)Alon Zakai2022-03-311-1/+1
| | | | | | | | | | | As we recently noted in #4555, that Feature::All and FeatureSet.setAll() are different is potentially confusing... I think the best thing is to make them identical. This does that, and adds a new Feature::AllPossible which is everything possible and not just the set of all features that are enabled by -all. This undoes part of #4555 as now the old/simpler code works properly.
* Add support for extended-const proposal (#4529)Sam Clegg2022-03-192-1/+3
| | | See https://github.com/WebAssembly/extended-const
* Make IndexedTypeNameGenerator more powerful (#4511)Thomas Lively2022-02-091-31/+36
| | | | | Allow IndexedTypeNameGenerator to be configured with a custom prefix and also allow it to be parameterized with an explicit fallback generator. This allows multiple IndexedTypeNameGenerators to be composed together, for example.
* Generate heap type names when printing types (#4503)Thomas Lively2022-02-076-195/+238
| | | | | | | | | | | | | | | | | | | | | | The previous printing system in the Types API would print the full recursive structure of a Type or HeapType with special markers using de Bruijn indices to avoid infinite recursion and a separate special marker for when the size exceeded an arbitrary upper limit. In practice, the types printed by that system were not human readable, so all that complexity was not useful. Replace that system with a new system that always emits a HeapType name rather than recursing into the structure of inner HeapTypes. Add methods for printing Types and HeapTypes with custom HeapType name generators. Also add a new wasm-type-printing.h header with off-the-shelf type name generators that implement simple naming schemes sufficient for tests and the type fuzzer. Note that these new printing methods and the old printing methods they augment are not used for emitting text modules. Printing types as part of expressions and modules is handled by separate code in Print.cpp and the printing API modified in this PR is mostly used for debugging. However, the new printing methods are general enough that Print.cpp should be able to use them as well, so update the format used to print types in the modified printing system to match the text format in anticipation of making that change in a follow-up PR.
* Make `TypeBuilder::build()` fallible (#4474)Thomas Lively2022-01-252-26/+26
| | | | | | | | | | | It is possible for type building to fail, for example if the declared nominal supertypes form a cycle or are structurally invalid. Previously we would report a fatal error and kill the program from inside `TypeBuilder::build()` in these situations, but this handles errors at the wrong layer of the code base and is inconvenient for testing the error cases. In preparation for testing the new error cases introduced by isorecursive typing, make type building fallible and add new tests for existing error cases. Also fix supertype cycle detection, which it turns out did not work correctly.
* Remove unused `isNominal` field on HeapTypeInfo (#4465)Thomas Lively2022-01-202-557/+0
| | | | | | | | This field was originally added with the goal of allowing types from multiple type systems to coexist by determining the type system on a per-type level rather than globally. This goal was never fully achieved and the `isNominal` field is not used outside of tests. Now that we are working on implementing the hybrid isorecursive system, it does not look like having types from multiple systems coexist will be useful in the near term, so clean up this tech debt.
* Introduce gtest (#4466)Thomas Lively2022-01-202-109/+0
| | | | | | | | | | | | | | | | | | | | | | | | Add gtest as a git submodule in third_party and integrate it into the build the same way WABT does. Adds a new executable, `binaryen-unittests`, to execute `gtest_main`. As a nontrivial example test, port one of the `TypeBuilder` tests from example/ to gtest/. Using gtest has a number of advantages over the current example tests: - Tests are compiled and linked at build time rather than runtime, surfacing errors earlier and speeding up test execution. - Tests are all built into a single binary, reducing overall link time and further reducing test overhead. - Tests are built from the same CMake project as the rest of Binaryen, so compiler settings (e.g. sanitizers) are applied uniformly rather than having to be separately set via the COMPILER_FLAGS environment variable. - Using the industry-standard gtest rather than our own script reduces our maintenance burden. Using gtest will lower the barrier to writing C++ tests and will hopefully lead to us having more proper unit tests.
* LiteralList => Literals (#4451)Alon Zakai2022-01-131-5/+16
| | | | | | | LiteralList overlaps with Literals, but is less efficient as it is not a SmallVector. Add reserve/capacity methods to SmallVector which are now necessary to compile.
* Do not track effects of immutable things (#4376)Alon Zakai2021-12-081-1/+0
| | | | We don't use those effects now in any way, and if we need them some day we can add them back. For now they just add overhead and complexity.
* Allow building basic HeapTypes in nominal mode (#4346)Thomas Lively2021-11-194-24/+83
| | | | | | | | | | | | | | | | As we work toward allowing nominal and structural types to coexist, any difference in how they can be built or used will be an inconvenient footgun that we will have to work around. In the spirit of reducing the differences between the type systems, allow TypeBuilder to construct basic HeapTypes in nominal mode just as it can in equirecursive mode. Although this change is a net increase in code complexity for not much benefit (wasm-opt never needs to build basic HeapTypes), it is also an incremental step toward getting rid of separate type system modes, so I expect it to simplify other PRs in the near future. This change also uncovered a bug in how the type fuzzer generated subtypes of basic HeapTypes. The generated subtypes did not necessarily have the intended `Kind`, which caused failures in nominal subtype validation in the fuzzer.
* Add table.grow operation (#4245)Max Graey2021-10-182-0/+11
|
* [Wasm GC] Take advantage of immutable struct fields in effects.h (#4240)Alon Zakai2021-10-131-1/+2
| | | | | | This is the easy part of using immutability more: Just note immutable fields as such when we read from them, and then a write to a struct does not interfere with such reads. That is, only a read from a mutable field can notice the effect of a write.
* Fix function name `BinaryenTableSizeSetTable` (#4230)Paulo Matos2021-10-121-1/+5
| | | | | `BinaryenTableSizeSetTable` was being declared in the header correctly, but defined as `BinaryenTableSetSizeTable`. Add test for `BinaryenTableSizeGetTable` and `BinaryenTableSizeSetTable`.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-12 06:32:46 +0000