| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
There is no reason the `__stack_pointer` global can't be exported from
the module, and in fact I'm experimenting with a non-relocatable main
module that requires this.
See https://github.com/emscripten-core/emscripten/issues/12682
This heuristic still kind of sucks but should always be good enough
for llvm output that always puts the stack pointer first.
|
|
|
|
|
|
|
|
| |
As it happens, this doesn't (normally) break the resulting EM_ASM or
EM_JS strings because (IIUC) JS supports the tab literal inside of
strings as well as "\t".
However, it's better to preserve the original text so that it looks
the same in the JS file as it did in the original source.
|
|
|
| |
See https://github.com/emscripten-core/emscripten/pull/15855
|
| |
|
| |
|
|
|
|
|
|
| |
Turns out just removing the mangling wasn't enough for
emscripten to support both before and after versions.
See https://github.com/WebAssembly/binaryen/pull/3785
|
|
|
| |
See https://github.com/emscripten-core/emscripten/pull/13847
|
|
|
|
| |
I'm not sure what `stack$init` is but I don't think its been
used for many years.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Passive element segments do not belong to any table, so the link between
Table and elem needs to be weaker; i.e. an elem may have a table in case
of active segments, or simply be a collection of function references in
case of passive/declarative segments.
This PR takes Table::Segment out and turns it into a first class module
element just like tables and functions. It also implements early support
for parsing, printing, encoding and decoding passive/declarative elem
segments.
|
|
|
| |
This as a consequence of https://reviews.llvm.org/D95651
|
| |
|
| |
|
|
|
|
|
|
|
| |
If we find a data segment whose entire contents is EM_JS or EM_ASM
strings then strip it from the binary.
See: https://github.com/emscripten-core/emscripten/pull/13443
|
|
|
|
|
|
|
|
| |
Support for multiple signatures per JS code string was removed in #2422.
emscripten now only needs to know that address and the body of the JS
function.
See https://github.com/emscripten-core/emscripten/pull/13452.
|
|
|
| |
Adds support for modules with multiple tables. Adds a field for the table name to `CallIndirect` and updates the C/JS APIs accordingly.
|
|
|
|
|
| |
This is a pure refactor in preparation for change that will
enable stripping or at least zeroing segments that only contain
EM_JS/EM_ASM strings.
|
|
|
|
|
|
| |
The algorithm was trying to remove all __em_js functions but it was
using the names of functions rather than export names so it was failing
to remove these functions unless the internal function names happened to
match (this turns out of the true for build with debug names).
|
|
|
|
|
|
|
|
|
|
| |
This used to return a simple name like "if" for an If, but it is redundant with
our proper printing logic. This PR turns it into a trivial helper that just prints
out the name of the class, so it now prints "If" with a capital. That is useful
for some logging, like in Metrics I think it is clearer than it was earlier (since
we are actually counting the classes, and our old emitting of text-format-like
names are just confusing, as we emitted "binary" there which is not valid).
Also replace some usages of that method with proper printing.
|
|
|
| |
See https://github.com/emscripten-core/emscripten/pull/13208
|
| |
|
|
|
|
|
| |
(#3431)
Also improved the LLD test scripts to accomodate 64-bit tests.
|
|
|
|
|
|
|
|
|
|
|
| |
With PIC + threads the offset of passive segments is not constant but
relative to `__memory_base`.
When trying to find passive segment offset based on the target of the
`memory.init` instruction we need to consider this possibility as well as
the regular constant one.
For the llvm side of this that generates the calls to memory.init
see: https://reviews.llvm.org/D92620
|
|
|
| |
Specifically try to cleanup use of asm_v_wasm.h and asmjs constants.
|
|
|
|
|
|
| |
Emscripten no longer needs this information as of
https://github.com/emscripten-core/emscripten/pull/12643.
This also removes the need to export __data_end.
|
| |
|
|
|
|
| |
The use of these passes was removed on the emscripten side
in https://github.com/emscripten-core/emscripten/pull/12536.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
|
|
| |
This depends on https://github.com/emscripten-core/emscripten/pull/12391
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Two new flags here, one to completely removes dynCalls, and another to
limit them to only signatures that contains i64.
See #3043
|
|
|
|
|
|
|
| |
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
|
|
|
| |
Since they make the code clearer and more self-documenting.
|
|
|
| |
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 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
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
| |
This should not be needed since in emscripten standalone mode we
always include a crt1.o that includes _start.
|
|
|
|
| |
Doing it this way happens to re-order the __assign_got_entries
function in the module, but its otherwise NFC.
|
|
|
| |
First step in making wasm-emscripten-finalize use more passes.
|
| |
|
|
|
|
| |
To avoid the conditional trailing comma.
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
These are now implemented in assembly as part of emscripten's
compiler-rt.
See: https://github.com/emscripten-core/emscripten/pull/11166
|
|
|
|
| |
This should allow https://github.com/emscripten-core/emscripten/pull/11166
to land, afterwhich we can completely remove these functions.
|
|
|
|
|
|
|
| |
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
|