summaryrefslogtreecommitdiff
path: root/src/wasm
Commit message (Collapse)AuthorAgeFilesLines
* Initial implementation of "Memory64" proposal (#3130)Wouter van Oortmerssen2020-09-185-88/+198
| | | Also includes a lot of new spec tests that eventually need to go into the spec repo
* Improve testing on Windows (#3142)Wouter van Oortmerssen2020-09-171-1/+1
| | | | | | This PR contains: - Changes that enable/disable tests on Windows to allow for better local testing. - Also changes many abort() into Fatal() when it is really just exiting on error. This is because abort() generates a dialog window on Windows which is not great in automated scripts. - Improvements to CMake to better work with the project in IDEs (VS).
* Unary and binary duplicate expression elimination (#3047)Max Graey2020-09-171-6/+6
| | | | | | | | | | | | | | | | | | Simplifies patterns in which an expression is applied twice to its operands. `abs(abs(x))` -> `abs(x)` `ceil(ceil(x))` -> `ceil(x)` `floor(floor(x))` -> `floor(x)` `trunc(trunc(x))` -> `trunc(x)` `nearest(nearest(x))` -> `nearest(x)` `eqz(eqz(bool(x)))` -> `bool(x)` `sext(sext(x))` -> `sext(x)` `neg(neg(x))` -> `x` `y - (y - x)` -> `x` `(x ^ y) ^ y` -> `x` `(x | y) | y` -> `x | y` `(x & y) & y` -> `x & y` `(x % y) % y` -> `x % y`
* Refactor Host expression to MemorySize and MemoryGrow (#3137)Daniel Wirtz2020-09-176-83/+60
| | | 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.
* Add GC feature flag (#3135)Daniel Wirtz2020-09-174-8/+8
| | | Adds the `--enable-gc` feature flag, so far enabling the `anyref` type incl. subtyping, and removes the temporary `--enable-anyref` feature flag that it replaces.
* Fix inner block problem with 'catch' (#3129)Heejin Ahn2020-09-151-19/+83
| | | Fixes #3114.
* Implement module and local names in name section (#3115)Daniel Wirtz2020-09-143-43/+143
| | | | | | | | | | | | | | | 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)
* Update Pop text format to handle tuples (#3116)Thomas Lively2020-09-111-2/+6
| | | | | | | | | | | Previously Pops were printed as ({type}.pop), and if the popped type was a tuple, something like ((i32, i64).pop) would get printed. However, the parser didn't support pops of anything besides single basic types. This PR changes the text format to be (pop <type>*) and adds support for parsing pops of tuples of basic types. The text format change is designed to make parsing simpler. This change is necessary for writing Poppy IR tests (see #3059) that contain break or return instructions that consume multiple values, since in Poppy IR that requires tuple-typed pops.
* Stop renaming longjmp in wasm-emscripten-finalize (#3111)Alon Zakai2020-09-111-8/+1
| | | | | | | | | | | Instead of finalize renaming emscripten_longjmp_jmpbuf to emscripten_longjmp, do nothing in finalize. But in the optional --post-emscripten pass, rename it there if both exist, so that we don't end up using two imports (other optimization passes can then remove an unneeded import). Depends on emscripten-core/emscripten#12157 to land first so that emscripten can handle both names, and it is just an optimization to have one or the other. See https://github.com/WebAssembly/binaryen/issues/3043
* Add anyref feature and type (#3109)Daniel Wirtz2020-09-107-6/+74
| | | Adds `anyref` type, which is enabled by a new feature `--enable-anyref`. This type is primarily used for testing that passes correctly handle subtype relationships so that the codebase will continue to be prepared for future subtyping. Since `--enable-anyref` is meaningless without also using `--enable-reference-types`, this PR also makes it a validation error to pass only the former (and similarly makes it a validation error to enable exception handling without enabling reference types).
* Poppy IR wast parsing and validation (#3105)Thomas Lively2020-09-093-5/+109
| | | | | 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.
* Interpreter: Don't change NaN bits when multiplying by 1 (#3096)Alon Zakai2020-09-091-13/+30
| | | | | | | | | | Similar to #2958, but for multiplication. I thought this was limited only to division (it doesn't happen for addition, for example), but the fuzzer found that it does indeed happen for multiplication as well. Overall these are kind of workarounds for the interpreter doing normal f32/f64 multiplications using the host CPU, so we pick up any oddness of its NaN behavior. Using soft float might be safer (but much slower).
* Update reference types (#3084)Daniel Wirtz2020-09-097-91/+191
| | | | | | | 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
* Optimize MergeBlocks by caching branch results (#3102)Alon Zakai2020-09-031-1/+0
| | | | | | | | | | | BranchSeekerCache caches the set of branches in a node + its children, and helps compute new results by looking in the cache and using data for the children. This avoids quadratic time in the common case of a post-walk on a tower of nested blocks which is common in a switch. Fixes #3090 . On the testcase there this pass goes from over a minute to less than a second.
* Harden exnref literals (#3092)Daniel Wirtz2020-09-021-8/+8
| | | | | * Make `Literal::type` immutable to guarantee that we do not lose track of `Literal::exn` by changing the literal's type * Add an assert to guarantee that we don't create `exnref` literals without an `ExceptionPackage` (for now) * Enforce rvalue reference when creating an `exnref` Literal from a `std::unique_ptr<ExceptionPackage>`, avoiding a redundant copy by means of requiring `std::move`
* Fix ExceptionPackage memory errors (#3088)Thomas Lively2020-09-011-4/+14
| | | | | | | | | | | First, adds an explicit destructor call to fix a memory leak in `Literal::operator=` in which existing `ExceptionPackage`s would be silently dropped. Next, changes `Literal::getExceptionPackage` to return the `ExceptionPackage` by value to avoid a use-after-free bug in the interpreter that was surfaced by the new destructor call. A future improvement would be to switch to using `std::variant`. Fixes #3087.
* Add new compound Rtt type (#3076)Daniel Wirtz2020-08-261-113/+215
| | | Extends compound types introduced in #3012 with a representation of `Rtt`s as described in the GC proposal, by also introducing the concept of a `HeapType` shared between `TypeInfo` and `Rtt`. Again, this should be a non-functional change since `Rtt`s are not used anywhere yet. Subtyping rules and updating the `xref` aliases is left for future work.
* wasm-emscripten-finalize: Add flags to limit dynCall creation (#3070)Sam Clegg2020-08-261-0/+20
| | | | | | Two new flags here, one to completely removes dynCalls, and another to limit them to only signatures that contains i64. See #3043
* Add new compound Signature, Struct and Array types (#3012)Daniel Wirtz2020-08-245-78/+438
| | | | | Extends the `Type` hash-consing infrastructure to handle type-parameterized and constructed types introduced in the typed function references and GC proposals. This should be a non-functional change since the new types are not used anywhere yet. Recursive type construction and canonicalization is also left as future work. Co-authored-by: Thomas Lively <tlively@google.com>
* Remove old EM_ASM handling method (#3069)Alon Zakai2020-08-211-63/+6
| | | | | | | The minimizeWasmChanges flag now does nothing (but new changes are coming, so keep it around) - this moves us to always doing the new way of things. With that we can update the tests. See #3043
* Use const modifier when dealing with types (#3064)Daniel Wirtz2020-08-207-23/+23
| | | Since they make the code clearer and more self-documenting.
* Replace Type::expand() with an iterator-based approach (#3061)Daniel Wirtz2020-08-198-104/+76
| | | 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.
* wasm-emscripten-finalize: Make EM_ASM modifications optional (#3044)Alon Zakai2020-08-191-13/+27
| | | | | | | | | | | | | | | | | | | | | | wasm-emscripten-finalize renames EM_ASM calls to have the signature in the name. This isn't actually useful - emscripten doesn't benefit from that. I think it was optimized in fastcomp, and in upstream we copied the general form but not the optimizations, and then EM_JS came along which is easier to optimize anyhow. This PR makes those changes optional: when not doing them, it just leaves the calls as they are. Emscripten will need some changes to handle that, but those are simple. For convenience this adds a flag to "minimize wasm changes". The idea is that this flag avoids needing a double-roll or other inconvenience as the changes need to happen in tandem on the emscripten side. The same flag can be reused for later changes similar to this one. When they are all done we can remove the flag. (Note how the code ifdefed by the flag can be removed once we no longer need the old way of doing things - that is, the new approach is simpler on the binaryen side). See #3043
* Prepare for compound types that are single but not basic (#3046)Daniel Wirtz2020-08-174-96/+101
| | | | | | | | | | | | | | 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.
* Refactor hashing (#3023)Daniel Wirtz2020-08-121-6/+7
| | | | | | | | | * Unifies internal hashing helpers to naturally integrate with std::hash * Removes the previous custom implementation * Computed hashes are now always size_t * Introduces a hash_combine helper * Fixes an overwritten partial hash in Relooper.cpp
* Added headers to CMake files (#3037)Wouter van Oortmerssen2020-08-101-0/+2
| | | This is needed for headers to show up in IDE projects, and has no other effect on the build.
* Move generateDynCallThunks into its own pass. NFC. (#3000)Sam Clegg2020-08-041-11/+0
| | | | | | The core logic is still living in EmscriptenGlueGenerator because its used also by fixInvokeFunctionNames. As a followup we can figure out how to make these more independent.
* Implement prototype v128.load{32,64}_zero instructions (#3011)Thomas Lively2020-08-035-0/+20
| | | | | | | | 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.
* Move stack-check into its own pass (#2994)Sam Clegg2020-07-271-111/+0
| | | | | This new pass takes an optional stack-check-handler argument which is the name of the function to call on stack overflow. If no argument is passed then it just traps.
* wasm-emscripten-finalize: remove exportWasiStart (#2986)Sam Clegg2020-07-271-25/+0
| | | | This should not be needed since in emscripten standalone mode we always include a crt1.o that includes _start.
* Move emscripten PIC ABI conversion to a pass. NFC. (#2985)Sam Clegg2020-07-242-175/+2
| | | | Doing it this way happens to re-order the __assign_got_entries function in the module, but its otherwise NFC.
* Move ReplaceStackPoint into a pass (#2984)Sam Clegg2020-07-241-57/+0
| | | First step in making wasm-emscripten-finalize use more passes.
* DWARF: Do not reorder locals in binary writing (#2959)Alon Zakai2020-07-232-4/+23
| | | | | | | | | | | | | | | | | | | | | The binary writer reorders locals unconditionally. I forgot about this, and so when I made DWARF disable optimization passes that reorder, this was left active. Optimally the writer would not do this, and the ReorderLocals pass would. But it looks like we need special logic for tuple locals anyhow, as they expand into multiple locals, so some amount of local order changes seems unavoidable atm. Test changes are mostly just lots of offsets, and can be ignored, but the new test test/passes/dwarf-local-order.* shows the issue. It prints $foo once, then after a roundtrip (showing no reordering), then it strips the DWARF section and prints after another roundtrip (which does show reordering). This also makes us avoid the Stack IR writer if DWARF is present, which matches what we do with source maps. This doesn't prevent any known bugs, but it's simpler this way and debugging + Stack IR opts is not an important combination.
* 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 a builder.makeConst helper template (#2971)Alon Zakai2020-07-211-2/+2
|
* Interpreter: Don't change NaN bits when dividing by 1 (#2958)Alon Zakai2020-07-151-0/+16
| | | | | | | | | | | | | | | | | | It's valid to change NaN bits in that case per the wasm spec, but if we do so then fuzz testcases will fail on the optimization of nan:foo / 1 => nan:foo That is, it is ok to leave the bits as they are, and if we do that then we are consistent with the simple and valid optimization of removing a divide by 1. Found by the fuzzer - looks like on x64 on some float32 NaNs, the bits will actually change (see the testcase). I've seen this on two machines consistently, so it's normal apparently. Disable an old wasm spectest that has been updated in upstream anyhow, but the new test here is even more strict and verifies the interpreter literally changes no bits.
* DWARF: Ignore debug_loc spans that are invalid (#2939)Alon Zakai2020-07-011-2/+3
| | | | | | | | An (x, y) span is updated to some (q, r) in the new binary. If q > r then the span is no longer valid - the optimizer has reordered things too much. It's possible this could be flipped, but I'm not certain. It seems safer to just omit these, which are very rare (I only see this on some larger testcases in the emscripten test suite).
* DWARF: Never emit (0, 0) to mean an empty span in debug_loc (#2940)Alon Zakai2020-07-011-0/+10
| | | | | | | | | After mapping to the new positions, and after relativizing to the base, if we end up with (0, 0) then we must emit something else, as that would be interpreted as the end of a list. As it is an empty span, the actual value doesn't matter, it just has to be != 0. This can happen if the very first span in a compile unit is an empty span, in which case relative to the base of the compile unit we would have (0, 0).
* DWARF: Always update .debug_loc base offsets (#2936)Alon Zakai2020-06-301-47/+88
| | | | | | | | | | | | | | | | | | | | | .debug_loc entries can have bases: a value that all values after it in the list are relative to. Previously we used to keep the base value as it was, to keep things as similar to the original DWARF as possible. However, if optimizations move code around so that the values after the base are before the base, then the values could no longer be emitted, and we skipped them in effect. This PR makes us always pick a new base for each list. This allows the base to always work for the values after it, but does mean we change the lists quite a lot more. If there is any extra meaning to the original bases here we may lose that, but the DWARF spec doesn't seem to indicate anything like that (however, it isn't clear to me why LLVM then doesn't always choose the maximal base as the code here does - LLVM's values seem oddly arbitrary). Also properly note the base of each compile unit, which previously we just noted the old value, but didn't look at the new one in the new binary being written.
* DWARF: Track sequences so that we can handle reordering within one (#2932)Alon Zakai2020-06-251-27/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we tracked sequence ends, so if an instruction was marked as the end, we'd keep marking it that way in the output. However, if X, Y, Z form a sequence that is then reordered into Z, Y, X then we need to emit the end on X now. To do that, give a "sequence number" to each debug line. Then when emitting, we can tell if two adjacent lines are in a sequence or not, and emit the end properly. This fixes a large partner testcase, allowing llvm-dwarfdump --verify --debug-line to pass on it. With this change it is easier to remove the hackish handling of prologueEnd that we had before, where we reset it. Instead, just emit it when it is set, and that's all. In particular we can get rid of the // Reset the state and resetAfterLine() calls in emitDiff. That function now just emits a diff, with no side effects, and is marked const. This refactoring moves the needToEmit() check to an earlier place. Instead of noting lines we'll never emit, don't even note them at all. The test diff seems large, but it is all due to one small change that then changes all the later offsets: - 0x00000831: 01 DW_LNS_copy - 0x000000000000086e 43 4 1 0 0 is_stmt + 0x00000831: 00 DW_LNE_end_sequence + 0x000000000000086e 43 4 1 0 0 is_stmt end_sequence Note how we add end_sequence there. We used to have an entry right after it with line 0 that was marked as the end of the sequence. In the new code, we don't emit that unnecessary line (which was previously only emitted for the end sequence!) and instead emit the end sequence on the last valid line.
* DWARF: Fix sequence_end emitting (#2929)Alon Zakai2020-06-241-2/+3
| | | | | | | | | | | | | We must emit those, even if otherwise it looks like a line we can omit, as the ends of sequences have important meaning and dwarfdump will warn without them. Looks like fannkuch0 in the test suite already had an example of an incorrectly-omitted sequence_end, so no need for a new testcase. Verified that without this e.g. wasm2.test_exceptions with -g added will lead to a wasm that warns, but with this PR the debug_line section is reported as valid by dwarfdump.
* Add Expression::dump for use while debugging (#2912)Thomas Lively2020-06-151-0/+8
| | | | | 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.
* Move optional metadata field so its not last (#2909)Sam Clegg2020-06-111-8/+8
| | | | To avoid the conditional trailing comma.
* Default mainReadsParams to true in standalone mode (#2906)Sam Clegg2020-06-111-15/+21
| | | | | | | The process of DCE'ing the argument handling is already handled in a different way in standalone more. In standalone mode the entry point is `_start` which takes no args, and argv code is included on-demand via the presence or absence the wasi syscalls for argument processing (__wasi_args_get/__wasi_args_sizes_get).
* Support new clang mangling of main (__main_argc_argv) (#2671)Sam Clegg2020-06-101-1/+17
| | | | | | | | | The plan is that for standlone mode we can function just like wasi-sdk and call the correct main from crt1.c. For non-standalone mode we still want to export can call main directly so we rename __main_argc_argv back to main as part of finalize. See https://reviews.llvm.org/D70700
* Rename anyref to externref to match proposal change (#2900)Jay Phelps2020-06-106-29/+29
| | | | | | | 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-055-0/+98
| | | As specified in https://github.com/WebAssembly/simd/pull/232.
* Fix DWARF location list updating with nonzero compilation unit base addr ↵Paolo Severini2020-05-271-3/+32
| | | | | | | | | | | | | | | | (#2862) In the .debug_loc section the Start/End address offsets in a location list are relative to the address of the compilation unit that refers that location list. There is a problem in function wasm::Debug:: updateLoc(), which compares these offsets with the actual module addresses of expressions and functions, causing the generation of invalid location lists. The fix is not trivial, because the DWARF debug_loc section does not specify which is the compilation unit associated to each location list entry. A simple workaround is to store, in LocationUpdater, a map of location list offsets to the base address of the compilation units referencing them, and that can be easily calculated in updateDIE().
* Remove `Push` (#2867)Thomas Lively2020-05-223-21/+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.
* Remove stackSave/stackAlloc/stackRestore code generation (#2852)Sam Clegg2020-05-201-158/+43
| | | | | | | These are now implemented in assembly as part of emscripten's compiler-rt. See: https://github.com/emscripten-core/emscripten/pull/11166
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-27 17:03:54 +0000