summaryrefslogtreecommitdiff
path: root/src/binaryen-c.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix Relooper leaking Branches (#3097)Daniel Wirtz2020-09-081-6/+5
| | | Fixes the `Relooper` leaking `Branch`es in `Optimizer::SkipEmptyBlocks`, by refactoring the API so a `std::unique_ptr` is ensured for each `Block`, `Branch` and `Shape` upon adding to the relooper.
* Improve inlining "heavyweight" (#3085)Max Graey2020-09-041-4/+4
| | | | | | | | | Split that mode into an option to check for loops (which indicate a function is "heavy") and a constant check for having calls. The case of calls is different as we would need more logic to avoid infinite recursion if we are willing to inling functions with calls. Practically, this renames allowHeavyweight to allowFunctionsWithLoops.
* Add Binaryen(Get|Set)AllowHeavyweight to binaryen-c.h (#3082)Max Graey2020-08-281-2/+2
| | | These declarations were previously missing causing the respective APIs to be not exposed. Also makes sure that a Boolean is returned by the JS API and adds a test to verify that it is working now.
* Add allowHeavyweight inlining option (#3032)Max Graey2020-08-261-0/+8
| | | | | As discussed in #2921, this allows inlining of functions not identified as "lightweight" (that include a loop, for example).
* Use const modifier when dealing with types (#3064)Daniel Wirtz2020-08-201-1/+1
| | | Since they make the code clearer and more self-documenting.
* Replace Type::expand() with an iterator-based approach (#3061)Daniel Wirtz2020-08-191-3/+4
| | | This leads to simpler code and is a prerequisite for #3012, which makes it so that not all `Type`s are backed by vectors that `expand` could return.
* Prepare for compound types that are single but not basic (#3046)Daniel Wirtz2020-08-171-2/+3
| | | | | | | | | | | | | | As a follow-up to https://github.com/WebAssembly/binaryen/pull/3012#pullrequestreview-459686171 this PR prepares for the new compound Signature, Struct and Array types that are single but not basic. This includes: * Renames `Type::getSingle` to `Type::getBasic` (NFC). Previously, its name was not representing its implementation (`isSingle` excluded `none` and `unreachable` while `getSingle` didn't, i.e. `getSingle` really was `getBasic`). Note that a hypothetical `Type::getSingle` cannot return `ValueType` anyway (new compound types are single but don't map to `ValueType`), so I figured it's best to skip implementing it until we actually need it. * Marks locations where we are (still) assuming that all single types are basic types, as suggested in https://github.com/WebAssembly/binaryen/pull/3012#discussion_r465356708, but using a macro, so we get useful errors once we start implementing the new types and can quickly traverse the affected locations. The macro is added where * there used to be a `switch (type.getSingle())` or similar that handled any basic type (NFC), but in the future will also have to handle single types that are not basic types. * we are not dealing with `Unary`, `Binary`, `Load`, `Store` or `AtomicXY` instructions, since these don't deal with compound types anyway.
* Extend the C- and JS-APIs (#2586)Daniel Wirtz2020-07-221-26/+1026
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Renames the following C-API functions BinaryenBlockGetChild to BinaryenBlockGetChildAt BinaryenSwitchGetName to BinaryenSwitchGetNameAt BinaryenCallGetOperand to BinaryenCallGetOperandAt BinaryenCallIndirectGetOperand to BinaryenCallIndirectGetOperandAt BinaryenHostGetOperand to BinaryenHostGetOperandAt BinaryenThrowGetOperand to BinaryenThrowGetOperandAt BinaryenTupleMakeGetOperand to BinaryenTupleMakeGetOperandAt Adds the following C-API functions BinaryenExpressionSetType BinaryenExpressionFinalize BinaryenBlockSetName BinaryenBlockSetChildAt BinaryenBlockAppendChild BinaryenBlockInsertChildAt BinaryenBlockRemoveChildAt BinaryenIfSetCondition BinaryenIfSetIfTrue BinaryenIfSetIfFalse BinaryenLoopSetName BinaryenLoopSetBody BinaryenBreakSetName BinaryenBreakSetCondition BinaryenBreakSetValue BinaryenSwitchSetNameAt BinaryenSwitchAppendName BinaryenSwitchInsertNameAt BinaryenSwitchRemoveNameAt BinaryenSwitchSetDefaultName BinaryenSwitchSetCondition BinaryenSwitchSetValue BinaryenCallSetTarget BinaryenCallSetOperandAt BinaryenCallAppendOperand BinaryenCallInsertOperandAt BinaryenCallRemoveOperandAt BinaryenCallSetReturn BinaryenCallIndirectSetTarget BinaryenCallIndirectSetOperandAt BinaryenCallIndirectAppendOperand BinaryenCallIndirectInsertOperandAt BinaryenCallIndirectRemoveOperandAt BinaryenCallIndirectSetReturn BinaryenCallIndirectGetParams BinaryenCallIndirectSetParams BinaryenCallIndirectGetResults BinaryenCallIndirectSetResults BinaryenLocalGetSetIndex BinaryenLocalSetSetIndex BinaryenLocalSetSetValue BinaryenGlobalGetSetName BinaryenGlobalSetSetName BinaryenGlobalSetSetValue BinaryenHostSetOp BinaryenHostSetNameOperand BinaryenHostSetOperandAt BinaryenHostAppendOperand BinaryenHostInsertOperandAt BinaryenHostRemoveOperandAt BinaryenLoadSetAtomic BinaryenLoadSetSigned BinaryenLoadSetOffset BinaryenLoadSetBytes BinaryenLoadSetAlign BinaryenLoadSetPtr BinaryenStoreSetAtomic BinaryenStoreSetBytes BinaryenStoreSetOffset BinaryenStoreSetAlign BinaryenStoreSetPtr BinaryenStoreSetValue BinaryenStoreGetValueType BinaryenStoreSetValueType BinaryenConstSetValueI32 BinaryenConstSetValueI64 BinaryenConstSetValueI64Low BinaryenConstSetValueI64High BinaryenConstSetValueF32 BinaryenConstSetValueF64 BinaryenConstSetValueV128 BinaryenUnarySetOp BinaryenUnarySetValue BinaryenBinarySetOp BinaryenBinarySetLeft BinaryenBinarySetRight BinaryenSelectSetIfTrue BinaryenSelectSetIfFalse BinaryenSelectSetCondition BinaryenDropSetValue BinaryenReturnSetValue BinaryenAtomicRMWSetOp BinaryenAtomicRMWSetBytes BinaryenAtomicRMWSetOffset BinaryenAtomicRMWSetPtr BinaryenAtomicRMWSetValue BinaryenAtomicCmpxchgSetBytes BinaryenAtomicCmpxchgSetOffset BinaryenAtomicCmpxchgSetPtr BinaryenAtomicCmpxchgSetExpected BinaryenAtomicCmpxchgSetReplacement BinaryenAtomicWaitSetPtr BinaryenAtomicWaitSetExpected BinaryenAtomicWaitSetTimeout BinaryenAtomicWaitSetExpectedType BinaryenAtomicNotifySetPtr BinaryenAtomicNotifySetNotifyCount BinaryenAtomicFenceSetOrder BinaryenSIMDExtractSetOp BinaryenSIMDExtractSetVec BinaryenSIMDExtractSetIndex BinaryenSIMDReplaceSetOp BinaryenSIMDReplaceSetVec BinaryenSIMDReplaceSetIndex BinaryenSIMDReplaceSetValue BinaryenSIMDShuffleSetLeft BinaryenSIMDShuffleSetRight BinaryenSIMDShuffleSetMask BinaryenSIMDTernarySetOp BinaryenSIMDTernarySetA BinaryenSIMDTernarySetB BinaryenSIMDTernarySetC BinaryenSIMDShiftSetOp BinaryenSIMDShiftSetVec BinaryenSIMDShiftSetShift BinaryenSIMDLoadSetOp BinaryenSIMDLoadSetOffset BinaryenSIMDLoadSetAlign BinaryenSIMDLoadSetPtr BinaryenMemoryInitSetSegment BinaryenMemoryInitSetDest BinaryenMemoryInitSetOffset BinaryenMemoryInitSetSize BinaryenDataDropSetSegment BinaryenMemoryCopySetDest BinaryenMemoryCopySetSource BinaryenMemoryCopySetSize BinaryenMemoryFillSetDest BinaryenMemoryFillSetValue BinaryenMemoryFillSetSize BinaryenRefIsNullSetValue BinaryenRefFuncSetFunc BinaryenTrySetBody BinaryenTrySetCatchBody BinaryenThrowSetEvent BinaryenThrowSetOperandAt BinaryenThrowAppendOperand BinaryenThrowInsertOperandAt BinaryenThrowRemoveOperandAt BinaryenRethrowSetExnref BinaryenBrOnExnSetEvent BinaryenBrOnExnSetName BinaryenBrOnExnSetExnref BinaryenTupleMakeSetOperandAt BinaryenTupleMakeAppendOperand BinaryenTupleMakeInsertOperandAt BinaryenTupleMakeRemoveOperandAt BinaryenTupleExtractSetTuple BinaryenTupleExtractSetIndex BinaryenFunctionSetBody Also introduces wrappers to the JS-API resembling the classes in C++ to perform the above operations on an expression. For example: var unary = binaryen.Unary(module.i32.eqz(1)); unary.getOp(...) / .op unary.setOp(...) / .op = ... unary.getValue(...) / .value unary.setValue(...) / .value = ... unary.getType(...) / .type unary.finalize() ... Usage of wrappers is optional, and one can also use plain functions: var unary = module.i32.eqz(1); binaryen.Unary.getOp(unary, ...) ... Also adds comments to all affected functions in case we'd like to generate API documentation at some point.
* Rename anyref to externref to match proposal change (#2900)Jay Phelps2020-06-101-3/+3
| | | | | | | anyref future semantics were changed to only represent opaque host values, and thus renamed to externref. [Chromium](https://bugs.chromium.org/p/v8/issues/detail?id=7748#c360) was just updated to today (not yet released). I couldn't find a Mozilla bugzilla ticket mentioning externref so I don't immediately know if they've updated yet. https://github.com/WebAssembly/reference-types/pull/87
* Add prototype SIMD rounding instructions (#2895)Thomas Lively2020-06-051-0/+8
| | | As specified in https://github.com/WebAssembly/simd/pull/232.
* Prevent pops from sinking in SimplifyLocals (#2885)Heejin Ahn2020-06-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents `exnref.pop`s from being sinked and separated from `catch`. For example, ```wast (try (do) (catch (local.set $0 (exnref.pop)) (call $foo (i32.const 3) (local.get $0) ) ) ) ``` Here, if we sink `exnref.pop` to remove `local.set $0` and `local.get $0`, it becomes this: ```wast (try (do) (catch (nop) (call $foo (i32.const 3) (exnref.pop) ) ) ) ``` This move was possible because `i32.const 3` does not have any side effects. But this is incorrect because now `exnref.pop` does not follow right after `catch`. To prevent this, this patch checks this case in `canSink` in SimplifyLocals. When we encountered a similar case in CodeFolding, we prevented every expression that contains `Pop` anywhere in it from being moved, which was too conservative. This adds `danglingPop` property in `EffectAnalyzer`, so that only pops that are not enclosed within a `catch` count as 'dangling pops` and we only prevent those pops from being moved or sinked.
* Remove `Push` (#2867)Thomas Lively2020-05-221-12/+0
| | | | | | Push and Pop have been superseded by tuples for their original intended purpose of supporting multivalue. Pop is still used to represent block arguments for exception handling, but there are no plans to use Push for anything now or in the future.
* Implement i64x2.mul (#2860)Thomas Lively2020-05-191-0/+1
| | | | This is the only instruction in the current spec proposal that had not yet been implemnented in the tools.
* Implement pseudo-min/max SIMD instructions (#2847)Thomas Lively2020-05-121-0/+4
| | | As specified in https://github.com/WebAssembly/simd/pull/122.
* Add C/JS APIs to copy expressions (#2840)Daniel Wirtz2020-05-111-0/+5
| | | | | | This API enables use cases where we want to keep the original expression, yet utilize passes like `vacuum` or `precompute` to evaluate it without implicitly modifying the original. C-API: **BinaryenExpressionCopy**(expr, module) JS-API: **Module#copyExpression**(expr)
* Remove C API tracing (#2841)Daniel Wirtz2020-05-081-2285/+194
| | | | | | This feature was very useful in the early days of the C API, but has not shown usefuless for quite a while, and has a significant maintenance burden, so it it's makes sense to remove it now.
* Refactor ExpressionRunner (#2804)Daniel Wirtz2020-04-271-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tackles the concerns raised in https://github.com/WebAssembly/binaryen/issues/2797 directly related to https://github.com/WebAssembly/binaryen/pull/2702 by reverting merging all of `PrecomputeExpressionRunner` into the base `ExpressionRunner`, instead adding a common base for both the precompute pass and the new C-API to inherit. No functional changes. --- ### Current hierarchy after https://github.com/WebAssembly/binaryen/pull/2702 is ``` ExpressionRunner ├ [PrecomputeExpressionRunner] ├ [CExpressionRunner] ├ ConstantExpressionRunner └ RuntimeExpressionRunner ``` where `ExpressionRunner` contains functionality not utilized by `ConstantExpressionRunner` and `RuntimeExpressionRunner`. ### New hierarchy will be: ``` ExpressionRunner ├ ConstantExpressionRunner │ ├ [PrecomputeExpressionRunner] │ └ [CExpressionRunner] ├ InitializerExpressionRunner └ RuntimeExpressionRunner ``` with the precompute pass's and the C-API's shared functionality now moved out of `ExpressionRunner` into a new `ConstantExpressionRunner`. Also renames the previous `ConstantExpressionRunner` to `InitializerExpressionRunner` to [better represent its uses](https://webassembly.org/docs/modules/#initializer-expression) and to make its previous name usable for the new intermediate template, where it fits perfectly. Also adds a few comments answering some of the questions that came up recently. ### Old hierarchy before https://github.com/WebAssembly/binaryen/pull/2702 for comparison: ``` ExpressionRunner ├ [PrecomputeExpressionRunner] ├ ConstantExpressionRunner └ RuntimeExpressionRunner ```
* Add BinaryenCallIsReturn/BinaryenCallIndirectIsReturn to C/JS API (#2779)Shao Cheng2020-04-221-0/+20
|
* Refactor expression runner so it can be used via the C and JS APIs (#2702)Daniel Wirtz2020-04-201-0/+138
| | | | | | | Refactors most of the precompute pass's expression runner into its base class so it can also be used via the C and JS APIs. Also adds the option to populate the runner with known constant local and global values upfront, and remembers assigned intermediate values as well as traversing into functions if requested.
* Use direct pointers as Type IDs (#2745)Thomas Lively2020-04-131-23/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using indices into the global interned type table. This means that a lock is *never* needed to access an expanded Type. The Type lock is now only acquired when a complex Type is created. On a real-world wasm2js workload this improves wall clock time by 23% on my machine with 72 cores and makes traffic on the Type lock entirely insignificant. **Before** 72 cores real 0m6.914s user 184.014s sys 0m3.995s 1 core real 0m25.903s user 0m25.658s sys 0m0.253s **After** 72 cores real 5.349s user 70.309s sys 9.691s 1 core real 25.859s user 25.615s sys 0.253s
* Tuple operations in C and JS APIs (#2711)Thomas Lively2020-03-261-66/+130
| | | | Adds functions for creating and inspecting tuple.make and tuple.extract expressions in the C and JS APIs.
* SIMD integer abs and bitmask instructions (#2703)Thomas Lively2020-03-201-0/+6
| | | | | | Adds full support for the {i8x16,i16x8,i32x4}.abs instructions merged to the SIMD proposal in https://github.com/WebAssembly/simd/pull/128 as well as the {i8x16,i16x8,i32x4}.bitmask instructions proposed in https://github.com/WebAssembly/simd/pull/201.
* Add multivalue feature (#2668)Thomas Lively2020-02-271-0/+3
|
* Add the GetFunctionTable JS API (#2554)COFFEETALES2020-02-201-0/+59
|
* Add C-/JS-APIs for inlining options (#2655)Daniel Wirtz2020-02-131-0/+48
| | | | | | | | | | Allows a user to modify the inlining limits using the C- and JS-APIs. * binaryen.**getAlwaysInlineMaxSize**(): `number` * binaryen.**setAlwaysInlineMaxSize**(size: `number`): `void` * binaryen.**getFlexibleInlineMaxSize**(): `number` * binaryen.**setFlexibleInlineMaxSize**(size: `number`): `void` * binaryen.**getOneCallerInlineMaxSize**(): `number` * binaryen.**setOneCallerInlineMaxSize**(size: `number`): `void`
* Add C-/JS-APIs for lowMemoryUnused and pass arguments (#2639)Daniel Wirtz2020-02-071-0/+58
| | | | | | | | | Allows a user to enable/disable the `lowMemoryUnused` option and to get/set/clear arbitrary pass arguments when using the C- or JS-APIs. * binaryen.**getLowMemoryUnused**(): `boolean` * binaryen.**setLowMemoryUnused**(on: `boolean`): `void` * binaryen.**getPassArgument**(key: `string`): `string | null` * binaryen.**setPassArgument**(key: `string`, value: `string | null`): `void` * binaryen.**clearPassArguments**(): `void`
* Add EH support for EffectAnalyzer (#2631)Heejin Ahn2020-02-031-3/+8
| | | | | | | | | | | | | | | | | | | | This adds EH support to `EffectAnalyzer`. Before `throw` and `rethrow` conservatively set property. Now `EffectAnalyzer` has a new property `throws` to represent an expression that can throw, and expression that can throw sets `throws` correctly. When EH is enabled, any calls can throw too, so we cannot reorder them with another expression with any side effects, meaning all calls should be treated in the same way as branches when evaluating `invalidate`. This prevents many reorderings, so this patch sets `throws` for calls only when the exception handling features is enabled. This is also why I passed `--disable-exception-handling` to `wasm2js` tests. Most of code changes outside of `EffectAnalyzer` class was made in order to pass `FeatureSet` to it. `throws` isn't always set whenever an expression contains a throwable instruction. When an throwable instruction is within an inner try, it will be caught by the corresponding inner catch, so it does not set `throws`.
* Unify JS memory segment API (#2533)Daniel Wirtz2020-01-211-0/+14
| | | | | | | | | | Binaryen.js now uses offset instead of byteOffset when inspecting a memory segment, matching the arguments on memory segment creation. Also adds inspection of the passive property. Previously, one would specify { offset, data, passive } on creation and get back { byteOffset, data } upon inspection. This PR unifies both to the keys on creation while also adding the respective C-API to retrieve passive status, which was missing.
* Expose ExpressionAnalyzer in C-/JS-API (#2585)Daniel Wirtz2020-01-171-0/+59
| | | | | | | Instead of reinventing the wheel on our side, this adds ExpressionAnalyzer bindings to the C- and JS-APIs, which can be useful for generators. For example, a generator may decide to simplify a compilation step if a subexpression doesn't have any side effects, or simply skip emitting something that is likely to compile to a drop or an empty block right away.
* Remove implicit conversion operators from Type (#2577)Thomas Lively2020-01-081-13/+13
| | | | | | | | | | * Remove implicit conversion operators from Type Now types must be explicitly converted to uint32_t with Type::getID or to ValueType with Type::getVT. This fixes #2572 for switches that use Type::getVT. * getVT => getSingle
* [NFC] Enforce use of `Type::` on type names (#2434)Thomas Lively2020-01-071-16/+16
|
* Use FeatureSet instead of FeatureSet::Feature(NFC) (#2562)Heejin Ahn2020-01-021-11/+11
| | | | | This uses `FeatureSet` in place of `FeatureSet::Feature` when possible, making it possible for functions take a set of multiple features as one argument.
* Add support for reference types proposal (#2451)Heejin Ahn2019-12-301-12/+89
| | | | | | | | | | | | This adds support for the reference type proposal. This includes support for all reference types (`anyref`, `funcref`(=`anyfunc`), and `nullref`) and four new instructions: `ref.null`, `ref.is_null`, `ref.func`, and new typed `select`. This also adds subtype relationship support between reference types. This does not include table instructions yet. This also does not include wasm2js support. Fixes #2444 and fixes #2447.
* SIMD {i8x16,i16x8}.avgr_u instructions (#2539)Thomas Lively2019-12-181-0/+2
| | | As specified in https://github.com/WebAssembly/simd/pull/126.
* Make local.tee's type its local's type (#2511)Heejin Ahn2019-12-121-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the current spec, `local.tee`'s return type should be the same as its local's type. (Discussions on whether we should change this rule is going on in WebAssembly/reference-types#55, but here I will assume this spec does not change. If this changes, we should change many parts of Binaryen transformation anyway...) But currently in Binaryen `local.tee`'s type is computed from its value's type. This didn't make any difference in the MVP, but after we have subtype relationship in #2451, this can become a problem. For example: ``` (func $test (result funcref) (local $0 anyref) (local.tee $0 (ref.func $test) ) ) ``` This shouldn't validate in the spec, but this will pass Binaryen validation with the current `local.tee` implementation. This makes `local.tee`'s type computed from the local's type, and makes `LocalSet::makeTee` get a type parameter, to which we should pass the its corresponding local's type. We don't embed the local type in the class `LocalSet` because it may increase memory size. This also fixes the type of `local.get` to be the local type where `local.get` and `local.set` pair is created from `local.tee`.
* Remove FunctionType (#2510)Thomas Lively2019-12-111-186/+30
| | | | | | | | | | | | | | | | | Function signatures were previously redundantly stored on Function objects as well as on FunctionType objects. These two signature representations had to always be kept in sync, which was error-prone and needlessly complex. This PR takes advantage of the new ability of Type to represent multiple value types by consolidating function signatures as a pair of Types (params and results) stored on the Function object. Since there are no longer module-global named function types, significant changes had to be made to the printing and emitting of function types, as well as their parsing and manipulation in various passes. The C and JS APIs and their tests also had to be updated to remove named function types.
* Add string parameter to WASM_UNREACHABLE (#2499)Sam Clegg2019-12-051-4/+4
| | | | | This works more like llvm's unreachable handler in that is preserves information even in release builds.
* Convert to using DEBUG macros (#2497)Sam Clegg2019-12-041-6/+6
| | | | | | This means that debugging/tracing can now be enabled and controlled centrally without managing and passing state around the codebase.
* Add Emscripten memory helpers for using the C-API (from Wasm) (#2476)Daniel Wirtz2019-12-031-1/+55
| | | | | | | | | | | | We already have exports for _malloc and _free in the Emscripten build, but there is no way yet to initialize the data without resorting to JS. Hence this PR adds a few additional memory helpers to the Emscripten build so it becomes possible to manipulate Binaryen memory without the need for extra glue code, for example when Binaryen is a WebAssembly import, and one is allocating strings to be used by / reading strings returned by Binaryen. I expect this to be a bit controversial because the use case is relatively specific, but it makes sense for us because we are consuming the C-API directly (from JS and eventually Wasm) and don't rely on binaryen.js-post.js.
* Use opaque types for handle references in C API (#2473)Ingvar Stepanyan2019-11-261-6/+6
| | | | This improves typechecking by verifying that user passes pointers of correct types.
* Remove FunctionType from Event (#2466)Thomas Lively2019-11-251-27/+16
| | | | | | | | | This is the start of a larger refactoring to remove FunctionType entirely and store types and signatures directly on the entities that use them. This PR updates BrOnExn and Events to remove their use of FunctionType and makes the BinaryWriter traverse the module and collect types rather than using the global FunctionType list. While we are collecting types, we also sort them by frequency as an optimization. Remaining uses of FunctionType in Function, CallIndirect, and parsing will be removed in a future PR.
* Multivalue type creation and inspection (#2459)Thomas Lively2019-11-221-0/+36
| | | | | | | | | | | | | Adds the ability to create multivalue types from vectors of concrete value types. All types are transparently interned, so their representation is still a single uint32_t. Types can be extracted into vectors of their component parts, and all the single value types expand into vectors containing themselves. Multivalue types are not yet used in the IR, but their creation and inspection functionality is exposed and tested in the C and JS APIs. Also makes common type predicates methods of Type and improves the ergonomics of type printing.
* uint32_t instead of int64_t as return type for GetMemorySegmentByteOffset ↵COFFEETALES2019-11-121-2/+2
| | | | | (#2432) `uint32_t` instead of `int64_t` as return type for `GetMemorySegmentByteOffset` and minor fixes on tests.
* Add i32x4.dot_i16x8_s (#2420)Thomas Lively2019-11-041-0/+3
| | | | | This experimental instruction is specified in https://github.com/WebAssembly/simd/pull/127 and is being implemented to enable further investigation of its performance impact.
* Add SIMD integer min and max instructions (#2416)Thomas Lively2019-11-011-0/+12
| | | As proposed in https://github.com/WebAssembly/simd/pull/27.
* Fix BinaryenModuleAllocateAndWriteText parameter type (#2406)Irmen de Jong2019-10-281-1/+1
| | | This fixes a compiler error when trying to compile code calling this function with a C++ compiler.
* Fix incorrect assert in BinaryenHostGetOperand (#2393)Brad Morris2019-10-221-1/+1
|
* Ability to list each item on Exports/Data Segments/Functions (#2386)COFFEETALES2019-10-211-0/+117
| | | Adds functionality to the C API for getting the number of items in a module and fetching them out by index.
* Add BinaryenAddCustomSection API (#2381)Daniel Wirtz2019-10-111-0/+31
| | | | This adds a new BinaryenAddCustomSection API so a generator can add arbitrary custom sections to a module.
* Add offset parameter to BinaryenSetFunctionTable (#2380)Daniel Wirtz2019-10-111-4/+5
| | | | | | This PR adds an offset parameter to BinaryenSetFunctionTable so table elements can start at the value of an (imported constant) global. Previously, the offset was fixed to zero. As usual this is a breaking change to the C-API but backwards compatible when using the JS-API.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-07 11:30:09 +0000