summaryrefslogtreecommitdiff
path: root/src/wasm
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Implement i64x2.mul (#2860)Thomas Lively2020-05-194-0/+11
| | | | This is the only instruction in the current spec proposal that had not yet been implemnented in the tools.
* [dwarf] Handle a bad mapped base in debug_loc updating (#2859)Alon Zakai2020-05-181-3/+17
| | | | Turns out we had a testcase for this already, but were doing the wrong thing on it.
* Don't warn 'skipping debug location info' (#2855)Alon Zakai2020-05-151-4/+0
| | | | | | That is only for the old source maps logic, not DWARF, and it is only useful to debug source maps (it's not actually useful for regular users that see the message) which we do not plan to do since DWARF is the future.
* Skip generating emscripten stack functions if they already exist (#2853)Sam Clegg2020-05-141-0/+9
| | | | This should allow https://github.com/emscripten-core/emscripten/pull/11166 to land, afterwhich we can completely remove these functions.
* Make 'do' clause mandatory in 'try' (#2851)Heejin Ahn2020-05-141-8/+7
| | | | | | | | | | | | | | Previously we were able to omit the new syntax `do` when `try` body is empty. This makes `do` clause mandatory, so when a `try` body is empty, the folded text format will be ``` (try (do) (catch ... ) ``` Suggested in https://github.com/WebAssembly/exception-handling/issues/52#issuecomment-626696720.
* Implement pseudo-min/max SIMD instructions (#2847)Thomas Lively2020-05-124-0/+64
| | | As specified in https://github.com/WebAssembly/simd/pull/122.
* Make try body start with 'do' (#2846)Heejin Ahn2020-05-111-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In WebAssembly/exception-handling#52, We decided to put `try` bodies in a `do` clause to be more consistent with `catch`. - Before ```wast (try ... (catch ... ) ) ``` - After ```wast (try (do ... ) (catch ... ) ) ``` Another upside of this change is when there are multiple instructions within a `try` body, we no longer need to wrap them in a `block`.
* Move std::hash specializations into the std namespace (#2835)Thomas Lively2020-05-061-8/+11
| | | | This hopefully fixes a build problem on older GCC as reported in #2827.
* Add interpreter support for EH (#2780)Heejin Ahn2020-05-061-1/+40
| | | | | | | | | This adds interpreter support for EH instructions. This adds `ExceptionPackage` struct, which contains info of a thrown exception (an event tag and thrown values), and the union in `Literal` can take a `unique_ptr` to `ExceptionPackage`. We need a destructor, a copy constructor, and an assignment operator for `Literal`, because the union in `Literal` now has a member that cannot be trivially copied or deleted.
* Add stack-pointer argument to post-emscripten pass. (#2823)Sam Clegg2020-05-011-6/+6
| | | | | | | This allows emscripten to statically set the initial value of the stack pointer. Should allow use to avoid doing it dynamically at startup: https://github.com/emscripten-core/emscripten/pull/11031
* Stop generating implementedFunctions in wasm-emscripten-finalize (#2819)Sam Clegg2020-04-281-9/+0
| | | | This list is identical to the export list no there is no need to output this twice.
* Emit section IDs as bytes (#2803)Thomas Lively2020-04-241-4/+4
| | | As described in the spec.
* Also update internal name in fixEmJsFuncsAndReturnWalker (#2782)Sam Clegg2020-04-211-17/+21
| | | | | | Without this change only the import gets renamed not the internal name. Since the internal name is the one that ends up in the name section this means that rename wasn't effecting the name section.
* Refactor expression runner so it can be used via the C and JS APIs (#2702)Daniel Wirtz2020-04-201-0/+1
| | | | | | | 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.
* Fix issues with Types and Features (#2773)Thomas Lively2020-04-161-2/+4
| | | | | | | | | 1. Only emit exnref as part of a subtype if exception-handling is enabled in the fuzzer. 2. Correctly report that funcref and nullref require reference-types to be enabled. 3. Re-enable multivalue as a normal feature in the fuzzer. Possibly fixes #2770.
* Validate that tuples have multiple operands (#2768)Thomas Lively2020-04-161-0/+2
| | | This was previously an unwritten and unchecked assumption.
* Fix build with a sprinkling of braces (#2766)Thomas Lively2020-04-141-11/+11
|
* Use direct pointers as Type IDs (#2745)Thomas Lively2020-04-131-75/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix invalid index checking in readImports (#2758)Heejin Ahn2020-04-131-1/+1
| | | Fixes #2751.
* Optimize uint32_t Type constructor (#2744)Thomas Lively2020-04-091-2/+5
| | | | | | Avoid taking the type interning lock to look up the size when the provided ID corresponds to a statically known type. This eliminates a considerable amount of unnecessary lock traffic when using the C or JS APIs.
* Handle tuples in Asyncify call support (#2743)Thomas Lively2020-04-091-0/+4
| | | | | Instead of adding globals for hardcoded basic types, traverse the module to collect all call types that might need to be handled and emit a global for each of them. Adapted from #2712.
* Performance optimizations for Type (#2733)Thomas Lively2020-04-092-27/+50
| | | | | | | Cache type sizes in unused bits from the type ID and rewrite some Type methods to avoid unnecessary calls to `expand` when the type is known to be a basic non-tuple type. This eliminates most of the locking traffic and reduces wall clock time by 52% and CPU time by 73% percent for one real-world program on my machine.
* Avoid g$ in main modules where possible (#2721)Alon Zakai2020-04-081-1/+28
| | | | | | | | | | We realized it is not valid to do these f$, g$ optimizations in main and side modules, as a symbol might appear in both (like RTTI or a weak symbol). We do need one of the appearances to "win". This does the g$ optimization in main modules only, that is, if a global appears in a main module then we can avoid a g$ import and instead compute its location directly in the module, since we will "win" over other modules with the same symbol anyhow.
* Only do fp$ optimization in the main module (#2720)Alon Zakai2020-04-071-7/+11
| | | | | | | | Weak symbols and interposition etc. mean that we should not replace an fp$ call with a symbol from the module itself if there is a chance there is another symbol that would have overridden it. In side modules this risk exists and so this PR makes us stop doing that. In main modules it is ok because they are loaded first and so any symbol they provide will "win" over others anyhow.
* Tuple globals (#2718)Thomas Lively2020-04-024-28/+58
| | | | | | | Since it wasn't easy to support tuples in Asyncify's call support using temporary functions, we decided to allow tuple-typed globals after all. This PR adds support for parsing, printing, lowering, and interpreting tuple globals and also adds validation ensuring that imported and exported globals do not have tuple types.
* Avoid unnecessary fp$ in side modules (#2717)Alon Zakai2020-03-311-29/+50
| | | | | | | | | | | | | | | | 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-13/+43
| | | | Update it from wasm-emscripten-finalize when we append to the table.
* Avoid fp$ access in MAIN_MODULES (#2704)Alon Zakai2020-03-271-11/+38
| | | | | | | | | | | | | | | | Depends on emscripten-core/emscripten#10741 which ensures that table indexes are unique. With that guarantee, a main module can just add its function pointers into the table, and use them based on that index. The loader will then see them in the table and then give other modules the identical function pointer for a function, ensuring function pointer equality. This avoids calling fp$ functions during startup for the main module's own functions (which are slow). We do still call fp$s of things we import from outside, as we don't have anything to put in the table for them, we depend on the loader for that. I suspect this can also be done with SIDE_MODULES, but did not want to try too much at once.
* Disallow tuples in MVP (#2707)Thomas Lively2020-03-242-1/+11
| | | | | | | | | Previously the multivalue feature enabled tuples in control flow positions, but tuples elsewhere did not require the multivalue feature. However, allowing tuple operations and locals in MVP modules means that all passes and tools need to support tuples, even if it isn't a high priority for them to support multivalue. Allowing tuples in MVP modules doesn't provide much value, so this changes disallows them entirely unless multivalue is enabled.
* Fix Event section ordering (#2708)Thomas Lively2020-03-241-1/+1
| | | The version of V8 pulled in by JSVU recently updated to expect the new ordering of the event section, so this PR should fix the CI.
* Allow subtypes in tuple operations (#2700)Thomas Lively2020-03-231-10/+13
| | | | | | Some optimizations may replace tuple elements with simpler values, and those simpler values may be a subtype of the original value. Tuple operations should continue to validate without being refinalized in these cases.
* SIMD integer abs and bitmask instructions (#2703)Thomas Lively2020-03-205-12/+96
| | | | | | 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.
* Support tuple locals in Asyncify (#2696)Thomas Lively2020-03-171-21/+24
| | | Iterate over tuple locals and separately load or store each component.
* Fix binary emitting of signature indices (#2694)Thomas Lively2020-03-162-1/+4
| | | | | It should be a signed LEB128, not an unsigned LEB128. This bug was causing modules to be invalid when the number of signatures in the type section was large and multivalue blocks were present.
* Collect signatures from all block kinds (#2691)Thomas Lively2020-03-161-0/+13
| | | | | | | | | Previously the signature collection mechanism responsible for populating the type section with signatures used by instructions only collected signatures from indirect call and block instructions. This works as long as all other control flow constructs like ifs, loops, and tries contain blocks with the same signature. But it is possible to have an if with non-block children, and we would need to collect its signature as well.
* Handle unreachable in TupleExtract::finalize (#2692)Thomas Lively2020-03-161-1/+7
|
* Update Precompute to handle tuples (#2687)Thomas Lively2020-03-101-2/+20
| | | | | | This involves replacing `Literal::makeZero` with `Literal::makeZeroes` and `Literal::makeSingleZero` and updating `isConstantExpression` to handle constant tuples as well. Also makes `Literals` its own struct and adds convenience methods on it.
* Handle multivalue returns in the interpreter (#2684)Thomas Lively2020-03-102-3/+30
| | | | Updates the interpreter to properly flow vectors of values, including at function boundaries. Adds a small spec test for multivalue return.
* Add 'warning:' to names section warning. Helps #2680 (#2683)Alon Zakai2020-03-091-1/+1
|
* Initial multivalue support (#2675)Thomas Lively2020-03-056-49/+305
| | | | | | | | | 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: Ignore a compile unit with no abbreviations (#2678)Alon Zakai2020-03-041-1/+1
| | | | | | | | | | Such a module can't have valid DIEs, since we have no way to interpret them. Also check if DWARF sections from LLVM have contents - when they are empty the section may exist but have a null for its data. Fixes #2673
* Improve a comment on unreachability [ci skip] (#2672)Alon Zakai2020-03-031-2/+13
|
* Simplify binary block parsing (#2674)Thomas Lively2020-02-281-36/+23
|
* Generalize binary writing for tuples (#2670)Thomas Lively2020-02-271-89/+24
| | | | | | | | | Updates `BinaryInstWriter::mapLocalsAndEmitHeader` so it no longer hardcodes each possible local type. Also adds a new inner loop over the elements of any local tuple type in the IR. Updates the map from IR local indices to binary indices to be additionally keyed on the index within a tuple type. Since we do not generate tuple types yet, this additional index is hardcoded to zero everywhere it is used for now. A later PR adding tuple creation operations will extend this functionality and add tests.
* Add multivalue feature (#2668)Thomas Lively2020-02-272-0/+5
|
* DWARF: Fix debug_range handling of invalid entries (#2662)Alon Zakai2020-02-181-18/+14
| | | | | | | | | | | | | | If an invalid entry appears - either it began as such, or became invalid after optimization - we should not emit (0, 0) which is an end marker. Instead, emit an invalid entry marker, something with (0, x) for x != 0. As a bonus, if a test/passes case has "noprint" in the name, don't print the wasm, which we do by default. In the testcase here for example we just care about the dwarf, and the printed module would be quite large. Thank you to @paolosevMSFT for identifying and suggesting the fix.
* DWARF: Update DW_AT_stmt_list which are offsets into the debug_line section ↵Alon Zakai2020-01-281-21/+51
| | | | | | | | (#2628) The debug_line section is the only one in which we change sizes and so must update offsets. It turns out that there are such offsets, DW_AT_stmt_list, so without updating them we can't handle multi-unit dwarf files.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-29 19:34:16 +0000