summaryrefslogtreecommitdiff
path: root/src/wasm/wasm-emscripten.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-241-175/+1
| | | | 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.
* Add a builder.makeConst helper template (#2971)Alon Zakai2020-07-211-2/+2
|
* 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
* 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
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
* Reland "Fix renaming in FixInvokeFunctionNamesWalker (#2513)" (#2622)Sam Clegg2020-01-241-15/+26
| | | | | This reverts commit 132daae1e9154782bb1afa5df80dfe7ea35f0369. This change is the same as before but the fix in #2619 should now make it safe.
* Revert "Reland "Fix renaming in FixInvokeFunctionNamesWalker (#2513)" ↵Sam Clegg2020-01-071-26/+15
| | | | | (#2542)" (#2576) This reverts commit f62e171c38bea14302f9b79f7941a248ea704425.
* [NFC] Enforce use of `Type::` on type names (#2434)Thomas Lively2020-01-071-36/+38
|
* Reland "Fix renaming in FixInvokeFunctionNamesWalker (#2513)" (#2542)Sam Clegg2019-12-201-15/+26
| | | | | | | | | | | | | | | | * Reland "Fix renaming in FixInvokeFunctionNamesWalker (#2513)" In the previous iteration of this change we were not calling `renameFunctions` for each of the functions we removed. The problem manifested itself when we rename the imported function to `emscripten_longjmp_jmpbuf` to `emscripten_longjmp`. In this case the import of `emscripten_longjmp` already exists so we remove the import of `emscripten_longjmp_jmpbuf` but we were not correclty calling renameFunctions to handle the rename of all the uses. Add an additional test case to cover the failures that we saw on the emscripten tree.
* Revert "Fix renaming in FixInvokeFunctionNamesWalker (#2513)" (#2541)Sam Clegg2019-12-191-13/+8
| | | This reverts commit f0a2e2c75c7bb3008f10b6edbb8dc4cfd27b7d28.
* Fix renaming in FixInvokeFunctionNamesWalker (#2513)Sam Clegg2019-12-171-8/+13
| | | | | | | | | | | | | This fixes https://github.com/emscripten-core/emscripten/issues/9950. The issue only shows up when debug names are not present so most of the changes in CL come from disabling debug names in the lld tests. We want to make sure that wasm-emscripten-finalize runs fine without debug names so I think it makes most sense to test in this mode. The actual bugfix is in wasm-emscripten.cpp as part of the FixInvokeFunctionNamesWalker. The problem was the name of the function rather than is import name was being added to importRenames. This means that when debug names were present (and the two names were the same) we didn't see the bug.
* Support stack overflow checks in standalone mode (#2525)Alon Zakai2019-12-121-5/+17
| | | | | | | | | In normal mode we call a JS import, but we can't import from JS in standalone mode. Instead, just trap in that case with an unreachable. (The error reporting is not as good in this case, but at least it catches all errors and halts, and the emitted wasm is valid for standalone mode.) Helps emscripten-core/emscripten#10019
* Make local.tee's type its local's type (#2511)Heejin Ahn2019-12-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the current spec, `local.tee`'s return type should be the same as its local's type. (Discussions on whether we should change this rule is going on in WebAssembly/reference-types#55, but here I will assume this spec does not change. If this changes, we should change many parts of Binaryen transformation anyway...) But currently in Binaryen `local.tee`'s type is computed from its value's type. This didn't make any difference in the MVP, but after we have subtype relationship in #2451, this can become a problem. For example: ``` (func $test (result funcref) (local $0 anyref) (local.tee $0 (ref.func $test) ) ) ``` This shouldn't validate in the spec, but this will pass Binaryen validation with the current `local.tee` implementation. This makes `local.tee`'s type computed from the local's type, and makes `LocalSet::makeTee` get a type parameter, to which we should pass the its corresponding local's type. We don't embed the local type in the class `LocalSet` because it may increase memory size. This also fixes the type of `local.get` to be the local type where `local.get` and `local.set` pair is created from `local.tee`.
* Remove FunctionType (#2510)Thomas Lively2019-12-111-66/+58
| | | | | | | | | | | | | | | | | Function signatures were previously redundantly stored on Function objects as well as on FunctionType objects. These two signature representations had to always be kept in sync, which was error-prone and needlessly complex. This PR takes advantage of the new ability of Type to represent multiple value types by consolidating function signatures as a pair of Types (params and results) stored on the Function object. Since there are no longer module-global named function types, significant changes had to be made to the printing and emitting of function types, as well as their parsing and manipulation in various passes. The C and JS APIs and their tests also had to be updated to remove named function types.
* Add some tracing to wasm-emscripten-finalize (#2505)Sam Clegg2019-12-051-0/+16
| | | | | Also fix, but in splitting the names of the trace channels. Obviously I can't write string.split correctly in C first time around.
* Add string parameter to WASM_UNREACHABLE (#2499)Sam Clegg2019-12-051-1/+1
| | | | | This works more like llvm's unreachable handler in that is preserves information even in release builds.
* Update type information for em_asm functions (#2480)Thomas Lively2019-11-261-1/+3
| | | | | | | | | We were only updating the imported Function's type name field and failing to update its params and results. This caused the binary writer to start using the wrong types after #2466. This PR fixes the code to update both type representations on the imported function. This double bookkeeping will be removed entirely in an upcoming PR.
* Don't attempt to de-duplicate asm consts (#2422)Sam Clegg2019-11-041-13/+11
| | | | | | | | | | | | Since we switched the using memory addresses for asm const indexes and stopping trying to modify the code we can no loner de-duplicate the asm const strings here. If we want to de-duplicate in the strings in emscripten we could do that but it seems like a marginal benefit. This fixes the test_html5_gamepad failures which is currently showing up on the emscripten waterfall.
* Use absolute memory addresses for emasm string indexes. (#2408)Sam Clegg2019-10-311-25/+36
| | | | | | | | | | Before we used 0-based indexes which meant that we needed to modify the code calling the emasm function to replace the first argument. Now we use the string address itself as the index/code for the emasm constant. This allows use code to go unmodifed as the emscripten side will accept the memory address as the index/code. See: https://github.com/emscripten-core/emscripten/issues/9013
* When renaming functions ensure the corresponding GOT.func entry is also ↵Sam Clegg2019-10-251-0/+7
| | | | | | renamed (#2382) Fixes https://github.com/WebAssembly/binaryen/issues/2180
* MAIN_THREAD_EM_ASM support (#2367)Jacob Gravelle2019-10-071-71/+113
| | | | | | | | | | | | * Support for sync and async main-thread EM_ASM * Fix up import names as well * update test * fix whitespace * clang-format
* Only create `_start` if it doesn't already exist (#2363)Sam Clegg2019-09-271-0/+3
|
* Add a --standalone-wasm flag to wasm-emscripten-finalize (#2333)Alon Zakai2019-09-181-0/+19
| | | The flag indicates that we want to run the wasm by itself, without JS support. In that case we don't emit JS dynCalls etc., and we also emit a wasi _start if there is a main, i.e., we try to use the current conventions in the wasm-only space.
* Fix infinite loop in AsmConstWalker::visitCall (#2303)Guanzhong Chen2019-08-161-1/+7
|
* Remove code to handle EM_ASM and setjmp/longjmp (#2302)Guanzhong Chen2019-08-161-135/+30
| | | | | | | | | This reverts commit 12add6f17c377de7ac334e8fa7885b61b98f3db4 (#2283). This is done due to the complexity of supporting EM_ASM and setjmp/longjmp, especially with dynamic linking thrown into the mix. In https://reviews.llvm.org/D66356, using EM_ASM and setjmp/longjmp in the same function is now an error.
* Fix EM_ASM not working with setjmp/longjmp (#2283)Guanzhong Chen2019-08-091-30/+135
|
* wasm-emscripten-finalize: Remove reliance on name section (#2285)Sam Clegg2019-08-061-3/+4
| | | | | | | | There were a couple of places where we were relying on internal names and therefore a name section. After this change wasm-emscripten-finalize works correctly on binaries without a name section at all and only relies on the names of imports and exports.
* Implement --check-stack-overflow flag for wasm-emscripten-finalize (#2278)Guanzhong Chen2019-08-021-3/+118
|
* Revert "Fix EM_ASM not working with setjmp/longjmp (#2271)" (#2277)Alon Zakai2019-08-011-128/+30
| | | | | This reverts commit 692f4666fd116fb7827b53348978f29bba253d47. See details in the reverted PR.
* Fix EM_ASM not working with setjmp/longjmp (#2271)Guanzhong Chen2019-07-311-30/+128
| | | | | This fix does not handle dynamic linking, which requires additional work. Refs https://github.com/emscripten-core/emscripten/issues/8894.
* wasm-emscripten-finalize: Add mainReadsParams metadata (#2247)Alon Zakai2019-07-221-1/+17
| | | | | | | The new flag indicates whether main reads the argc/argv parameters. If it does not, we can avoid emitting code to generate those arguments in the JS, which is not trivial in small programs - it requires some string conversion code. Nicely the existing test inputs were enough for testing this (see outputs). This depends on an emscripten change to land first, as emscripten.py asserts on metadata fields it doesn't recognize.
* Generalize EM_JS parsing code. (#2233)Alon Zakai2019-07-181-27/+6
| | | | | The key thing is that there is a single constant, which may or may not be saved/loaded from a local, and may or may not get an added global if in relocatable code. Fixes emscripten-core/emscripten#8993
* Handle passive segments in wasm-emscripten-finalize (#2217)Thomas Lively2019-07-111-2/+36
|
* Don't minify __stack_pointer import (#2219)Sam Clegg2019-07-111-1/+1
| | | This is core import like __memory_base and __table_base.
* wasm-emscripten-finalize: Internalize mutable __stack_pointer import (#2213)Sam Clegg2019-07-101-0/+26
| | | | | | | | | | | I'm working on a change to lld that will cause `-pie` binaries to import __stack_pointer, just like -shared do already. Because we don't yet support mutable globals everywhere this change will internalize the import and create a new immutable import that is used to initialize the internal one. This change is part of the fix for: https://github.com/emscripten-core/emscripten/issues/8915
* Ignore --initial-stack-pointer arg to wasm-emscripten-finalize (#2201)Sam Clegg2019-07-101-9/+0
| | | | | | | | | | | | | We were passing bad value in --initial-stack-pointer which did not include the STATIC_BUMP (since STATIC_BUMP is determinted by the output of finalize). If emscripten wants to set the stack pointer position it can do so by calling the stackRestore() function at startup. This argument will be removed completely once we stop passing it on the emscripten side. See https://github.com/emscripten-core/emscripten/issues/8905
* Reflect instruction renaming in code (#2128)Heejin Ahn2019-05-211-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Reflected new renamed instruction names in code and tests: - `get_local` -> `local.get` - `set_local` -> `local.set` - `tee_local` -> `local.tee` - `get_global` -> `global.get` - `set_global` -> `global.set` - `current_memory` -> `memory.size` - `grow_memory` -> `memory.grow` - Removed APIs related to old instruction names in Binaryen.js and added APIs with new names if they are missing. - Renamed `typedef SortedVector LocalSet` to `SetsOfLocals` to prevent name clashes. - Resolved several TODO renaming items in wasm-binary.h: - `TableSwitch` -> `BrTable` - `I32ConvertI64` -> `I32WrapI64` - `I64STruncI32` -> `I64SExtendI32` - `I64UTruncI32` -> `I64UExtendI32` - `F32ConvertF64` -> `F32DemoteI64` - `F64ConvertF32` -> `F64PromoteF32` - Renamed `BinaryenGetFeatures` and `BinaryenSetFeatures` to `BinaryenModuleGetFeatures` and `BinaryenModuleSetFeatures` for consistency.
* rename some C++ locals to camelCase for consistency (#2122)Alon Zakai2019-05-171-15/+15
|
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-10 03:28:21 +0000