summaryrefslogtreecommitdiff
path: root/src/wasm.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Prototype SIMD instructions implemented in LLVM (#3440)Thomas Lively2020-12-111-1/+17
| | | | | | - i64x2.eq (https://github.com/WebAssembly/simd/pull/381) - i64x2 widens (https://github.com/WebAssembly/simd/pull/290) - i64x2.bitmask (https://github.com/WebAssembly/simd/pull/368) - signselect ops (https://github.com/WebAssembly/simd/pull/124)
* [GC] Add ref.test and ref.cast (#3439)Alon Zakai2020-12-111-2/+8
| | | | This adds enough to read and write them and test that, but leaves interpreter support for later.
* [GC] Add Array operations (#3436)Alon Zakai2020-12-101-4/+24
| | | | | | | | | | | | | | array.new/get/set/len - pretty straightforward after structs and all the infrastructure for them. Also fixes validation of the unnecessary heapType param in the text and binary formats in structs as well as arrays. Fixes printing of packed types in type names, which emitted i32 for them. That broke when we emitted the same name for an array of i8 and i32 as in the new testing here. Also fix a bug in Field::operator< which was wrong for packed types; again, this was easy to notice with the new testing.
* Read and write data segments names in names section (#3435)Sam Clegg2020-12-091-0/+2
|
* [GC] Add struct.new and start to test interesting execution (#3433)Alon Zakai2020-12-091-2/+10
| | | | | | | | | | | | | | With struct.new read/write support, we can start to do interesting things! This adds a test of creating a struct and seeing that references behave like references, that is, if we write to the value X refers to, and if Y refers to the same thing, when reading from Y's value we see the change as well. The test is run through all of -O1, which uncovered a minor issue in Precompute: We can't try to precompute a reference type, as we can't replace a reference with a value. Note btw that the test shows the optimizer properly running CoalesceLocals on reference types, merging two locals.
* [GC] Add basic RTT support (#3432)Alon Zakai2020-12-081-2/+4
| | | | | | | | | | | | | | | | This adds rtt.canon and rtt.sub together with RTT type support that is necessary for them. Together this lets us test roundtripping the instructions and types. Also fixes a missing traversal over globals in collectHeapTypes, which the example from the GC docs requires, as the RTTs are in globals there. This does not yet add full interpreter support and other things. It disables initial contents on GC in the fuzzer, to avoid the fuzzer breaking. Renames the binary ID for exnref, which is being removed from the spec, and which overlaps with the binary ID for rtt.
* [GC] Add struct.set (#3430)Alon Zakai2020-12-071-2/+6
| | | | | | | | | | Mostly straightforward after struct.get. This renames the value field in struct.get to ref. I think this makes more sense because struct.set has both a reference to a thing, and a value to set onto that thing. So calling the former ref seems more consistent, giving us ref, value. This mirrors load/store for example where we use ptr, value, and ref is playing the role of ptr here basically.
* [GC] Add struct.get instruction parsing and execution (#3429)Alon Zakai2020-12-071-1/+6
| | | | | | | | | | | | | | | | | | | | This is the first instruction that uses a GC Struct or Array, so it's where we start to actually need support in the interpreter for those values, which is added here. GC data is modeled as a gcData field on a Literal, which is just a Literals. That is, both a struct and an array are represented as an array of values. The type which is alongside would indicate if it's a struct or an array. Note that the data is referred to using a shared_ptr so it should "just work", but we'll only be able to really test that once we add struct.new and so can verify that references are by reference and not value, etc. As the first instruction to care about i8/16 types (which are only possible in a Struct or Array) this adds support for parsing and emitting them. This PR includes fuzz fixes for some minor things the fuzzer found, including some bad printing of not having ResultTypeName in necessary places (found by the text format roundtripping fuzzer).
* [TypedFunctionReferences] Implement call_ref (#3396)Alon Zakai2020-11-241-0/+12
| | | | | | | | Includes minimal support in various passes. Also includes actual optimization work in Directize, which was easy to add. Almost has fuzzer support, but the actual makeCallRef is just a stub so far. Includes s-parser support for parsing typed function references types.
* [TypedFunctionReferences] Add Typed Function References feature and use the ↵Alon Zakai2020-11-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | types (#3388) This adds the new feature and starts to use the new types where relevant. We use them even without the feature being enabled, as we don't know the features during wasm loading - but the hope is that given the type is a subtype, it should all work out. In practice, if you print out the internal type you may see a typed function reference-specific type for a ref.func for example, instead of a generic funcref, but it should not affect anything else. This PR does not support non-nullable types, that is, everything is nullable for now. As suggested by @tlively this is simpler for now and leaves nullability for later work (which will apparently require let or something else, and many passes may need to be changed). To allow this PR to work, we need to provide a type on creating a RefFunc. The wasm-builder.h internal API is updated for this, as are the C and JS APIs, which are breaking changes. cc @dcodeIO We must also write and read function types properly. This PR improves collectSignatures to find all the types, and also to sort them by the dependencies between them (as we can't emit X in the binary if it depends on Y, and Y has not been emitted - we need to give Y's index). This sorting ends up changing a few test outputs. InstrumentLocals support for printing function types that are not funcref is disabled for now, until we figure out how to make that work and/or decide if it's important enough to work on. The fuzzer has various fixes to emit valid types for things (mostly whitespace there). Also two drive-by fixes to call makeTrivial where it should be (when we fail to create a specific node, we can't just try to make another node, in theory it could infinitely recurse). Binary writing changes here to replace calls to a standalone function to write out a type with one that is called on the binary writer object itself, which maintains a mapping of type indexes (getFunctionSignatureByIndex).
* Module splitting (#3317)Thomas Lively2020-11-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds the capability to programatically split a module into a primary and secondary module such that the primary module can be compiled and run before the secondary module has been instantiated. All calls to secondary functions (i.e. functions that have been split out into the secondary module) in the primary module are rewritten to be indirect calls through the table. Initially, the table slots of all secondary functions contain references to imported placeholder functions. When the secondary module is instantiated, it will automatically patch the table to insert references to the original functions. The process of module splitting involves these steps: 1. Create the new secondary module. 2. Export globals, events, tables, and memories from the primary module and import them in the secondary module. 3. Move the deferred functions from the primary to the secondary module. 4. For any secondary function exported from the primary module, export in its place a trampoline function that makes an indirect call to its placeholder function (and eventually to the original secondary function), allocating a new table slot for the placeholder if necessary. 5. Rewrite direct calls from primary functions to secondary functions to be indirect calls to their placeholder functions (and eventually to their original secondary functions), allocating new table slots for the placeholders if necessary. 6. For each primary function directly called from a secondary function, export the primary function if it is not already exported and import it into the secondary module. 7. Replace all references to secondary functions in the primary module's table segments with references to imported placeholder functions. 8. Create new active table segments in the secondary module that will replace all the placeholder function references in the table with references to their corresponding secondary functions upon instantiation. Functions can be used or referenced three ways in a WebAssembly module: they can be exported, called, or placed in a table. The above procedure introduces a layer of indirection to each of those mechanisms that removes all references to secondary functions from the primary module but restores the original program's semantics once the secondary module is instantiated. As more mechanisms that reference functions are added in the future, such as ref.func instructions, they will have to be modified to use a similar layer of indirection. The code as currently written makes a few assumptions about the module that is being split: 1. It assumes that mutable-globals is allowed. This could be worked around by introducing wrapper functions for globals and rewriting secondary code that accesses them, but now that mutable-globals is shipped on all browsers, hopefully that extra complexity won't be necessary. 2. It assumes that all table segment offsets are constants. This simplifies the generation of segments to actively patch in the secondary functions without overwriting any other table slots. This assumption could be relaxed by 1) having secondary segments re-write primary function slots as well, 2) allowing addition in segment offsets, or 3) synthesizing a start function to modify the table instead of using segments. 3. It assumes that each function appears in the table at most once. This isn't necessarily true in general or even for LLVM output after function deduplication. Relaxing this assumption would just require slightly more complex code, so it is a good candidate for a follow up PR. Future Binaryen work for this feature includes providing a command line tool exposing this functionality as well as C API, JS API, and fuzzer support. We will also want to provide a simple instrumentation pass for finding dead or late-executing functions that would be good candidates for splitting out. It would also be good to integrate that instrumentation with future function outlining work so that dead or exceptional basic blocks could be split out into a separate module.
* MemoryPacking: Properly notice zeroFilledMemory (#3306)Alon Zakai2020-11-021-1/+1
| | | We can only pack memory if we know it is zero-filled before us.
* Prototype new SIMD multiplications (#3291)Thomas Lively2020-10-281-0/+13
| | | | | | | Including saturating, rounding Q15 multiplication as proposed in https://github.com/WebAssembly/simd/pull/365 and extending multiplications as proposed in https://github.com/WebAssembly/simd/pull/376. Since these are just prototypes, skips adding them to the C or JS APIs and the fuzzer, as well as implementing them in the interpreter.
* DWARF: Fix handling of the end of control flow instructions (#3288)Alon Zakai2020-10-271-12/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously when we processed a block for example, we'd do this: ;; start is here (block (result type) ;; end is here .. contents .. ) ;; end delimiter is here Not how this represents the block's start and end as the "header", and uses an extra delimiter to mark the end. I think this is wrong, and was an attempt to handle some offsets from LLVM that otherwise made no sense, ones at the end of the "header". But it turns out that this makes us completely incorrect on some things where there is a low/high pc pair, and we need to understand that the end of a block is at the end opcode at the very end, and not the end of the header. This PR changes us to do that, i.e. ;; start is here (block (result type) .. contents .. ) ;; end is here This fixes a testcase already in the test suite, test/passes/fib_nonzero-low-pc_dwarf.bin.txt where you can see that lexical block now has a valid value for the end, and not a 0 (the proper scope extends all the way to the end of the big block in that function, and is now the same in the DWARF before and after we process it). test/passes/fannkuch3_dwarf.bin.txt is also improved by this. To implement this, this removes the BinaryLocations::End delimeter. After this we just need one type of delimiter actually, but I didn't refactor that any more to keep this PR small (see TODO). This removes an assertion in writeDebugLocationEnd() that is no longer valid: the assert ensures that we wrote an end only if there was a 0 for the end, but for a control flow structure, we write the end of the "header" automatically like for any expression, and then overwrite it later when we finish writing the children and the end marker. We could in theory special-case control flow structures to avoid the first write, but it would add more complexity. This uncovered what appears to be a possible bug in our debug_line handling, see test/passes/fannkuch3_manyopts_dwarf.bin.txt. That needs to be looked into more, but I suspect that was invalid info from when we looked at the end of the "header" of control flow structures. Note that there was one definite bug uncovered here, fixed by the extra } else if (locationUpdater.hasOldExprEnd(oldAddr)) { that is added here, which was definitely a bug.
* Implement i8x16.popcnt (#3286)Thomas Lively2020-10-271-0/+1
| | | | | | As proposed in https://github.com/WebAssembly/simd/pull/379. Since this instruction is still being evaluated for inclusion in the SIMD proposal, this PR does not add support for it to the C/JS APIs or to the fuzzer. This PR also performs a drive-by fix for unrelated instructions in c-api-kitchen-sink.c
* [NFC] `using namespace Abstract` to make matchers more compact (#3284)Thomas Lively2020-10-261-1/+1
| | | | | | | | | This change makes matchers in OptimizeInstructions more compact and readable by removing the explicit `Abstract::` namespace from individual operations. In some cases, this makes multi-line matcher expressions fit on a single line. This change is only possible because it also adds an explicit "RMW" prefix to each element of the `AtomicRMWOp` enumeration. Without that, their names conflicted with the names of Abstract ops.
* Implement v128.{load,store}{8,16,32,64}_lane instructions (#3278)Thomas Lively2020-10-221-1/+32
| | | | | | | These instructions are proposed in https://github.com/WebAssembly/simd/pull/350. This PR implements them throughout Binaryen except in the C/JS APIs and in the fuzzer, where it leaves TODOs instead. Right now these instructions are just being implemented for prototyping so adding them to the APIs isn't critical and they aren't generally available to be fuzzed in Wasm engines.
* Only write explicit names to name section (#3241)Sam Clegg2020-10-151-5/+15
| | | | Fixes: #3226
* Refactor naming convention for functions handling tuples (#3196)Max Graey2020-10-091-1/+1
| | | When there are two versions of a function, one handling tuples and the other handling non-tuple values, the previous naming convention was to have "Single" in the name of the non-tuple handling function. This PR simplifies the convention and shortens function names by making the names plural for the tuple-handling version and singular for the non-tuple-handling version.
* Add static guards for cast and dynCast (#3201)Max Graey2020-10-081-1/+13
|
* GC: Add stubs for the remaining instructions (#3174)Daniel Wirtz2020-09-291-0/+96
| | | NFC, except adding most of the boilerplate for the remaining GC instructions. Each implementation site is marked with a respective `TODO (gc): theInstruction` in between the typical boilerplate code.
* Lower signed binops to unsigned binops when possible (#2988)Max Graey2020-09-281-2/+2
| | | This can unlock further instruction optimizations that do not apply to signed operations.
* GC: Add i31 instructions (#3154)Daniel Wirtz2020-09-241-0/+21
| | | Adds the `i31.new` and `i31.get_s/u` instructions for creating and working with `i31ref` typed values. Does not include fuzzer integration just yet because the fuzzer expects that trivial values it creates are suitable in global initializers, which is not the case for trivial `i31ref` expressions.
* GC: Add ref.eq instruction (#3145)Daniel Wirtz2020-09-211-0/+11
| | | With `eqref` now integrated, the `ref.eq` instruction can be implemented. The only valid LHS and RHS value is `(ref.null eq)` for now, but implementation and fuzzer integration is otherwise complete.
* Initial implementation of "Memory64" proposal (#3130)Wouter van Oortmerssen2020-09-181-18/+23
| | | Also includes a lot of new spec tests that eventually need to go into the spec repo
* Refactor Host expression to MemorySize and MemoryGrow (#3137)Daniel Wirtz2020-09-171-8/+14
| | | Aligns the internal representations of `memory.size` and `memory.grow` with other more recent memory instructions by removing the legacy `Host` expression class and adding separate expression classes for `MemorySize` and `MemoryGrow`. Simplifies related APIs, but is also a breaking API change.
* Implement module and local names in name section (#3115)Daniel Wirtz2020-09-141-1/+5
| | | | | | | | | | | | | | | Adds support for the module and local subsections of the name section plus the respective C and JS APIs to populate and obtain local names. C API: * BinaryenFunctionGetNumLocals(func) * BinaryenFunctionHasLocalName(func, index) * BinaryenFunctionGetLocalName(func, index) * BinaryenFunctionSetLocalName(func, index, name) JS API: * Function.getNumLocals(func) * Function.hasLocalName(func, index) * Function.getLocalName(func, index) * Function.setLocalName(func, index, name)
* Poppy IR wast parsing and validation (#3105)Thomas Lively2020-09-091-0/+3
| | | | | Adds an IR profile to each function so the validator can determine which validation rules to apply and adds a flag to have the wast parser set the profile to Poppy for testing purposes.
* Update reference types (#3084)Daniel Wirtz2020-09-091-0/+2
| | | | | | | Align with the current state of the reference types proposal: * Remove `nullref` * Remove `externref` and `funcref` subtyping * A `Literal` of a nullable reference type can now represent `null` (previously was type `nullref`) * Update the tests and temporarily comment out those tests relying on subtyping
* Implement prototype v128.load{32,64}_zero instructions (#3011)Thomas Lively2020-08-031-1/+3
| | | | | | | | Specified in https://github.com/WebAssembly/simd/pull/237. Since these are just prototypes necessary for benchmarking, this PR does not add support for these instructions to the fuzzer or the C or JS APIs. This PR also renumbers the QFMA instructions that previously used the opcodes for these new instructions. The renumbering matches the renumbering in V8 and LLVM.
* Extend the C- and JS-APIs (#2586)Daniel Wirtz2020-07-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add Expression::dump for use while debugging (#2912)Thomas Lively2020-06-151-0/+3
| | | | | I have found that similar dump functions have been extremely helpful while debugging LLVM. Rather than re-implement this locally whenever I need it, it would be better have this utility upstream.
* Add prototype SIMD rounding instructions (#2895)Thomas Lively2020-06-051-0/+8
| | | As specified in https://github.com/WebAssembly/simd/pull/232.
* Remove `Push` (#2867)Thomas Lively2020-05-221-20/+2
| | | | | | 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.
* Fix an old misleading comment (#2738) [ci skip]Alon Zakai2020-04-091-2/+2
|
* Avoid unnecessary fp$ in side modules (#2717)Alon Zakai2020-03-311-1/+1
| | | | | | | | | | | | | | | | Now that we update the dylink section properly, we can do the same optimization in side modules as in main ones: if the module provides a function, don't call an $fp method during startup, instead add it to the table ourselves and use the relative offset to the table base. Fix an issue when the table has no segments initially: the code just added an offset of 0, but that's not right. Instead, an a __table_base import and use that as the offset. As this is ABI-specific I did it on wasm-emscripten-finalize, leaving TableUtils to just assert on having a singleton segment. Add a test of a wasm file with a dylink section to the lld tests.
* Represent dylink section in IR, so we can update it. (#2715)Alon Zakai2020-03-301-0/+10
| | | | Update it from wasm-emscripten-finalize when we append to the table.
* 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.
* Handle multivalue returns in the interpreter (#2684)Thomas Lively2020-03-101-1/+2
| | | | Updates the interpreter to properly flow vectors of values, including at function boundaries. Adds a small spec test for multivalue return.
* Initial multivalue support (#2675)Thomas Lively2020-03-051-0/+21
| | | | | | | | | Implements parsing and emitting of tuple creation and extraction and tuple-typed control flow for both the text and binary formats. TODO: - Extend Precompute/interpreter to handle tuple values - C and JS API support/testing - Figure out how to lower in stack IR - Fuzzing
* DWARF: Track more function locations (#2604)Alon Zakai2020-01-221-2/+12
| | | | | | | | | | | | | | DWARF from LLVM can refer to the first byte belonging to the function, where the size LEB is, or to the first byte after that, where the local declarations are, or the end opcode, or to one byte past that which is one byte past the bytes that belong to the function. We aren't sure why LLVM does this, but track it all for now. After this all debug line positions are identified. However, in some cases a debug line refers to one past the end of the function, which may be an LLVM bug. That location is ambiguous as it could also be the first byte of the next function (what made this discovery possible was when this happened to the last function, after which there is another section).
* DWARF: Track the positions of 'end', 'else', 'catch' binary locations (#2603)Alon Zakai2020-01-211-0/+34
| | | | | | | | | | | | | | | | | Control flow structures have those in addition to the normal span of (start, end), and we need to track them too. Tracking them during reading requires us to track control flow structures while parsing, so that we can know to which structure an end/else/catch refers to. We track these locations using a map on the side of instruction to its "extra" locations. That avoids increasing the size of the tracking info for the much more common non-control flow instructions. Note that there is one more 'end' location, that of the function (not referring to any instruction). I left that to a later PR to not increase this one too much.
* Handle an invalid AbbrCode in DWARF handling (#2607)Alon Zakai2020-01-211-1/+1
| | | | | | | | | | | | | Fixes the testcase in #2343 (comment) Looks like that's from Rust. Not sure why it would have an invalid abbreviation code, but perhaps the LLVM there emits dwarf differently than we've tested on so far. May be worth investigating further, but for now emit a warning, skip that element, and don't crash. Also fix valgrind warnings about Span values not being initialized, which was invalid and bad as well (wasted memory in our maps, and might have overlapped with real values), and interfered with figuring this out.
* Use BinaryLocation instead of hardcoding uint32_t (#2598)Alon Zakai2020-01-161-2/+7
| | | | This will make it easier to switch to something else for offsets in wasm binaries if we get >4GB files.
* DWARF: high_pc computation (#2595)Alon Zakai2020-01-161-2/+2
| | | | | | | Update high_pc values. These are interesting as they may be a relative offset compared to the low_pc. For functions we already had both a start and an end. Add such tracking for instructions as well.
* DWARF: Function location tracking (#2592)Alon Zakai2020-01-161-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Track the beginning and end of each function, both when reading and writing. We track expressions and functions separately, instead of having a single big map of (oldAddr) => (newAddr) because of the potentially ambiguous case of the final expression in a function: it's end might be identical in offset to the end of the function. So we have two different things that map to the same offset. However, if the context is "the end of the function" then the updated address is the new end of the function, even if the function ends with a different instruction now, as the old last instruction might have moved or been optimized out. Concretely, we have getNewExprAddr and getNewFuncAddr, so we can ask to update the location of either an expression or a function, and use that contextual information. This checks for the DIE tag in order to know what we are looking for. To be safe, if we hit an unknown tag, we halt, so that we don't silently miss things. As the test updates show, the new things we can do thanks to this PR are to update compile unit and subprogram low_pc locations. Note btw that in the first test (dwarfdump_roundtrip_dwarfdump.bin.txt) we change 5 to 0: that is correct since that test does not write out DWARF (it intentionally has no -g), so we do not track binary locations while writing, and so we have nothing to update to (the other tests show actual updating). Also fix the order in the python test runner code to show a diff of expected to encountered, and not the reverse, which confused me.
* [NFC] Enforce use of `Type::` on type names (#2434)Thomas Lively2020-01-071-6/+8
|
* Add support for reference types proposal (#2451)Heejin Ahn2019-12-301-0/+32
| | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-22 20:22:19 +0000