summaryrefslogtreecommitdiff
path: root/src/wasm/wasm-emscripten.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove now-redundant stack pointer manipulation passes (#3251)Sam Clegg2020-10-181-26/+0
| | | | The use of these passes was removed on the emscripten side in https://github.com/emscripten-core/emscripten/pull/12536.
* Rename Emscripten EHSjLj functions in wasm backend (#3191)Heejin Ahn2020-10-101-129/+1
| | | | | | | | | | | Now that we are renaming invoke wrappers and `emscripten_longjmp_jmpbuf` in the wasm backend, this deletes all related renaming routines and relevant tests. Depends on #3192. Addresses: #3043 and #3081 Companions: https://reviews.llvm.org/D88697 emscripten-core/emscripten#12399
* Let GenerateDynCalls generate dynCalls for invokes (#3192)Heejin Ahn2020-10-021-66/+0
| | | | | | This moves dynCall generating functionaity for invokes from `EmscriptenGlueGenerator` to `GenerateDynCalls` pass. So now `GenerateDynCalls` pass will take care of all cases we need dynCalls: functions in tables and invokes.
* Stop generating __growWasmMemory (#3180)Sam Clegg2020-10-011-13/+0
| | | This depends on https://github.com/emscripten-core/emscripten/pull/12391
* Refactor Host expression to MemorySize and MemoryGrow (#3137)Daniel Wirtz2020-09-171-1/+1
| | | 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.
* 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
* 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
* 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-201-2/+2
| | | Since they make the code clearer and more self-documenting.
* Replace Type::expand() with an iterator-based approach (#3061)Daniel Wirtz2020-08-191-11/+10
| | | 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
* 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.
* 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
|
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-17 19:35:58 +0000