summaryrefslogtreecommitdiff
path: root/src/wasm
Commit message (Collapse)AuthorAgeFilesLines
* 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
* 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
|
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-27 16:27:28 +0000