summaryrefslogtreecommitdiff
path: root/src/binaryen-c.h
Commit message (Collapse)AuthorAgeFilesLines
* [C API] Add getters and setters for various GC/Strings expressions (#5037)dcode2022-09-141-0/+379
| | | 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/+3
| | | | BinaryenSetMemory (#4963)
* 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.
* Add remaining GC and string instructions to C API (#4998)dcode2022-08-311-10/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [C/JS API] Avoid erroring in BinaryenSetMemoryImport etc. if the entity ↵Max Graey2022-08-301-0/+4
| | | | | | exists (#4991) If it exists, just turn it into an import. If not, then as before we create it + turn it into an import.
* Fix multi-memory + C API for MemoryGrow and MemorySize (#4953)Alon Zakai2022-08-231-2/+4
| | | | | | | | | | | | | | | | 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
* Multi-Memories improvements to binaryen-c.cpp (#4940)Ashley Nelson2022-08-191-14/+16
| | | | | | Resolving a couple of issues from the multi-memories PR landing: Use memName as parameter label instead of name #4916 Add helper func for case of a single memory to binaryen-c #4917
* Restore the `extern` heap type (#4898)Thomas Lively2022-08-171-0/+1
| | | | | | | 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-31/+53
| | | | | | | 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-6/+0
| | | | | | | 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-041-0/+122
| | | 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.
* [JS Api] Reuse C-Api for emitText and emitStackIR (#4832)Max Graey2022-07-291-3/+5
| | | Make the C API match the JS API and fix an old bug where extra newlines were emitted.
* [C/JS API] Add string reference types (#4810)dcode2022-07-271-0/+4
|
* [C/JS API] Expose string reference feature (#4831)Max Graey2022-07-261-0/+1
|
* [C-API] Add utility to go between types and heap types (#4792)dcode2022-07-141-0/+9
|
* [C-API] Add type system C-API (#4790)dcode2022-07-131-0/+10
|
* [C-API] Add packed type constants for use with GC types (#4791)dcode2022-07-121-0/+8
|
* Add C API for printing stack IR (#4692)ApsarasX2022-06-031-0/+16
| | | | | | | | BinaryenModulePrintStackIR: similar to BinaryenModulePrint BinaryenModuleWriteStackIR: similar to BinaryenModuleWriteText BinaryenModuleAllocateAndWriteStackIR: similar to BinaryenModuleAllocateAndWriteText
* Add C and JS API functions for accessing memory info (#4682) Jackson Gardner2022-05-241-0/+9
| | | Based on #3573 plus minor fixes
* [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.
* Add support for extended-const proposal (#4529)Sam Clegg2022-03-191-0/+1
| | | See https://github.com/WebAssembly/extended-const
* [C API] Fix BinaryenTypeCreate argument numTypes type (#4417)chai20102022-01-061-1/+1
| | | All other numXxxs argument use BinaryenIndex type.
* Add table.grow operation (#4245)Max Graey2021-10-181-1/+26
|
* Add table.size operation (#4224)Max Graey2021-10-081-0/+9
|
* Add table.set operation (#4215)Max Graey2021-10-071-0/+45
|
* Add feature flag for relaxed-simd (#4183)Ng Zhi An2021-09-231-0/+1
|
* Support specialized function types in element segments (#4109)Alon Zakai2021-09-021-0/+4
| | | | | | Before this, the element segments would be printed as having type funcref, and then if their table had a specialized type, the element type would not be a subtype of the table and validation would fail.
* Use the new module version of EffectAnalyzer (#4116)Alon Zakai2021-08-311-1/+1
| | | | | | | | | | | This finishes the refactoring started in #4115 by doing the same change to pass a Module into EffectAnalyzer instead of features. To do so this refactors the fallthrough API and a few other small things. After those changes, this PR removes the old feature constructor of EffectAnalyzer entirely. This requires a small breaking change in the C API, changing BinaryenExpressionGetSideEffects's feature param to a module. That makes this change not NFC, but otherwise it is.
* [API] Add type argument for BinaryenAddTable method (#4107)Max Graey2021-08-271-1/+2
| | | In the JS API this is optional and it defaults to `funcref`.
* Add TrapsNeverHappen to SideEffects's API (#4086)Max Graey2021-08-171-0/+1
|
* [JS/C API] Expose zeroFilledMemory option for JS and C API (#4071)Max Graey2021-08-131-0/+7
|
* [EH] Make tag's attribute encoding detail (#3947)Heejin Ahn2021-06-211-4/+0
| | | | | | | | | This removes `attribute` field from `Tag` class, making the reserved and unused field known only to binary encoder and decoder. This also removes the `attribute` parameter from `makeTag` and `addTag` methods in wasm-builder.h, C API, and Binaryen JS API. Suggested in https://github.com/WebAssembly/binaryen/pull/3946#pullrequestreview-687756523.
* [EH] Replace event with tag (#3937)Heejin Ahn2021-06-181-67/+65
| | | | | | | | | | | We recently decided to change 'event' to 'tag', and to 'event section' to 'tag section', out of the rationale that the section contains a generalized tag that references a type, which may be used for something other than exceptions, and the name 'event' can be confusing in the web context. See - https://github.com/WebAssembly/exception-handling/issues/159#issuecomment-857910130 - https://github.com/WebAssembly/exception-handling/pull/161
* Rename wasm-delegations[-fields].h to def files (NFC) (#3941)Heejin Ahn2021-06-181-1/+1
| | | | | | | | | | | These files are special in that they use define symbols that are not defined within those files or other files included in those files; they are supposed to be defined in source files that include these headers. This has caused clang-tidy to fail every time these files have changed because they are not compilable per se. This PR solves the problem by changing their extension to `def`, which is also used in LLVM codebase. LLVM has dozens of files like this whose extension is `def`, which makes these not checked by clang-tidy.
* Add SIMDLoadStoreLane get/setters to C/JS API (#3904)Daniel Wirtz2021-05-251-0/+44
|
* Fix typo in function name: BinayenElementSegmentIsPassive (#3862)Paulo Matos2021-05-061-1/+1
| | | Becomes BinaryenElementSegmentIsPassive
* Rename SIMD extending load instructions (#3798)Daniel Wirtz2021-04-121-6/+6
| | | | | | | | | Renames the SIMD instructions * LoadExtSVec8x8ToVecI16x8 -> Load8x8SVec128 * LoadExtUVec8x8ToVecI16x8 -> Load8x8UVec128 * LoadExtSVec16x4ToVecI32x4 -> Load16x4SVec128 * LoadExtUVec16x4ToVecI32x4 -> Load16x4UVec128 * LoadExtSVec32x2ToVecI64x2 -> Load32x2SVec128 * LoadExtUVec32x2ToVecI64x2 -> Load32x2UVec128
* Rename various SIMD load instructions (#3795)Daniel Wirtz2021-04-111-6/+6
| | | | | | | | | Renames the SIMD instructions * LoadSplatVec8x16 -> Load8SplatVec128 * LoadSplatVec16x8 -> Load16SplatVec128 * LoadSplatVec32x4 -> Load32SplatVec128 * LoadSplatVec64x2 -> Load64SplatVec128 * Load32Zero -> Load32ZeroVec128 * Load64Zero -> Load64ZeroVec128
* Add v128.load/storeN_lane SIMD instructions to C/JS API (#3784)Daniel Wirtz2021-04-081-0/+16
| | | | | | | | | | | Adds C/JS APIs for the SIMD instructions * Load8LaneVec128 (was LoadLaneVec8x16) * Load16LaneVec128 (was LoadLaneVec16x8) * Load32LaneVec128 (was LoadLaneVec32x4) * Load64LaneVec128 (was LoadLaneVec64x2) * Store8LaneVec128 (was StoreLaneVec8x16) * Store16LaneVec128 (was StoreLaneVec16x8) * Store32LaneVec128 (was StoreLaneVec32x4) * Store64LaneVec128 (was StoreLaneVec64x2)
* Add v128.load32/64_zero SIMD instructions to C/JS API (#3783)Daniel Wirtz2021-04-081-1/+2
| | | | | Adds C/JS APIs for the SIMD instructions * Load32Zero * Load64Zero
* Add new SIMD multiplication instructions to C/JS API (#3782)Daniel Wirtz2021-04-081-2/+13
| | | | | | | | | | | | | | | | Adds C/JS APIs for the SIMD instructions * Q15MulrSatSVecI16x8 * ExtMulLowSVecI16x8 * ExtMulHighSVecI16x8 * ExtMulLowUVecI16x8 * ExtMulHighUVecI16x8 * ExtMulLowSVecI32x4 * ExtMulHighSVecI32x4 * ExtMulLowUVecI32x4 * ExtMulHighUVecI32x4 * ExtMulLowSVecI64x2 * ExtMulHighSVecI64x2 * ExtMulLowUVecI64x2 * ExtMulHighUVecI64x2
* Add new SIMD conversion instructions to C/JS API (#3781)Daniel Wirtz2021-04-081-0/+6
| | | | | | | | | Adds C/JS APIs for the SIMD instructions * ConvertLowSVecI32x4ToVecF64x2 * ConvertLowUVecI32x4ToVecF64x2 * TruncSatZeroSVecF64x2ToVecI32x4 * TruncSatZeroUVecF64x2ToVecI32x4 * DemoteZeroVecF64x2ToVecF32x4 * PromoteLowVecF32x4ToVecF64x2
* Add iNxM.extadd_pairwise_* SIMD instructions to C/JS API (#3780)Daniel Wirtz2021-04-081-1/+4
| | | | | | | Adds C/JS APIs for the SIMD instructions * ExtAddPairwiseSVecI8x16ToI16x8 * ExtAddPairwiseUVecI8x16ToI16x8 * ExtAddPairwiseSVecI16x8ToI32x4 * ExtAddPairwiseUVecI16x8ToI32x4
* Add i64x2.extend_low/high_* SIMD instructions to C/JS API (#3778)Daniel Wirtz2021-04-071-0/+4
| | | | | | | Adds C/JS APIs for the SIMD instructions * ExtendLowSVecI32x4ToVecI64x2 * ExtendHighSVecI32x4ToVecI64x2 * ExtendLowUVecI32x4ToVecI64x2 * ExtendHighUVecI32x4ToVecI64x2
* Add various SIMD instructions to C/JS API (#3777)Daniel Wirtz2021-04-071-1/+10
| | | | | | | | | | | | | Adds C/JS APIs for the SIMD instructions * PopcntVecI8x16 * AbsVecI64x2 * AllTrueVecI64x2 * BitmaskVecI64x2 * EqVecI64x2 * NeVecI64x2 * LtSVecI64x2 * GtSVecI64x2 * LeSVecI64x2 * GeSVecI64x2
* Update SIMD names and opcodes (#3771)Thomas Lively2021-04-051-20/+9
| | | | Also removes experimental SIMD instructions that were not included in the final spec proposal.
* Use stdbool boolean instead of int to represent boolean values in C API (#3670)Paulo Matos2021-03-171-45/+47
| | | Fixes #3664
* Use uint32_t for Event Attribute in API (#3671)Paulo Matos2021-03-101-1/+1
|
* [reference-types] Support passive elem segments (#3572)Abbas Mashayekh2021-03-051-23/+55
| | | | | | | | | | | Passive element segments do not belong to any table, so the link between Table and elem needs to be weaker; i.e. an elem may have a table in case of active segments, or simply be a collection of function references in case of passive/declarative segments. This PR takes Table::Segment out and turns it into a first class module element just like tables and functions. It also implements early support for parsing, printing, encoding and decoding passive/declarative elem segments.
* Add C and JS API bindings for ref.as_* (#3628)Daniel Wirtz2021-03-011-0/+20
|
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-07 01:45:47 +0000