| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
| |
(#2384)
In this mode crt1 takes care of calling it.
|
| |
|
|
| |
This adds a new BinaryenAddCustomSection API so a generator can add arbitrary
custom sections to a module.
|
| |
|
|
|
|
| |
This PR adds an offset parameter to BinaryenSetFunctionTable so table elements
can start at the value of an (imported constant) global. Previously, the offset
was fixed to zero. As usual this is a breaking change to the C-API but backwards
compatible when using the JS-API.
|
| |
|
|
| |
`exnref` is enabled by not reference type feature but exception handling
feature. Sorry that I missed this in #2377.
|
| |
|
|
|
| |
`pop` is not a real instruction and automatically generated when reading
binary and deleted when writing binary, so this does not work with
instrumentation.
|
| | |
|
| |
|
| |
This adds support for anyref and exnref types in InstrumentLocals pass.
|
| |
|
|
| |
This adds push/pop support for anyref. This also adds missing C API
tests for push/pop.
|
| |
|
|
|
|
|
|
|
| |
Previously we didn't print an additional block when there are multiple
instructions within a `try` body, so those wast files cannot be parsed
correctly, because the wast parser assumes there are two bodies within a
`try` scope: a try body and a catch body.
We don't need to print an additional block for a `catch` body because
`(catch ...)` itself serves as a scope.
|
| |
|
|
| |
The capitalisation causes issues on case-sensitive file systems,
for example when cross-compiling binaryen for windows.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Support for sync and async main-thread EM_ASM
* Fix up import names as well
* update test
* fix whitespace
* clang-format
|
| |
|
|
| |
As specified at
https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#swizzling-using-variable-indices.
|
| |
|
|
|
| |
We've had an option to set the location of the sbrk ptr, but not the value.
Applying the value as well is necessary for standalone wasm, as otherwise we set
it in JS.
|
| |
|
|
|
|
| |
Sometimes wasm-metadce is the last tool to run over a binary in
Emscripten, and in that case it needs to know what features are
enabled in order to emit a valid binary. For example it needs to know
whether to emit a data count section.
|
| | |
|
| |
|
|
|
|
| |
Adds support for the new load and extend instructions. Also updates
from C++11 to C++17 in order to use generic lambdas in the interpreter
implementation.
|
| |
|
|
|
| |
As specified at https://github.com/WebAssembly/simd/pull/102.
Also fixes bugs in the JS API for other SIMD bitwise operators.
|
| |
|
|
|
|
|
| |
Introduces a new instruction class, `SIMDLoad`. Implements encoding,
decoding, parsing, printing, and interpretation of the load and splat
instructions, including in the C and JS APIs. `v128.load` remains in
the `Load` instruction class for now because the interpreter code
expects a `Load` to be able to load any memory value type.
|
| |
|
|
|
|
|
|
|
| |
This is part of the fix for
https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket.appspot.com/8901492015302662960/+/steps/Emscripten_testsuite__upstream__other_/0/stdout
Specifically it fixes that the name shown there should not be escaped.
Followup for #2344
|
| | |
|
| |
|
| |
See emscripten-core/emscripten#9381 for rationale.
|
| |
|
|
|
|
|
|
| |
Even though we do support python3 and if the python in your path
happens to be python3 that will work just fine, we also want to
continue to support those users who still only have python2 (i.e.
mac users who are relying on the default system python).
See https://github.com/emscripten-core/emsdk/issues/356
|
| |
|
|
|
| |
On Windows, symbols have to be explicitly exported to make them visible/accessible in a shared library. Binaryen.dll currently doesn't export any symbols as a result.
Marking all exported methods as `BINARYEN_API` that is defined as `__declspec(dllexport)` on Windows, unless building a static library.
|
| | |
|
| |
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This optimizes stuff like
(global.set $x (i32.const 123))
(global.get $x)
into
(global.set $x (i32.const 123))
(i32.const 123)
This doesn't help much with LLVM output as it's rare to use globals (except for the stack pointer, and that's already well optimized), but it may help on general wasm. It can also help with Asyncify that does use globals extensively.
|
| |
|
|
|
| |
With the optional asserts, we throw if we see an unwind begin in code that we thought could never unwind (say, because the user incorrectly blacklisted it).
Helps with emscripten-core/emscripten#9389
|
| | |
|
| |
|
| |
In #2328 the SIMDBitselect API has been replaced with SIMDTernary that now has Bitselect as one of multiple operations, which is currently not exposed, unlike the new QFMA/QFMS operations which are exposed. This PR adds it.
|
| | |
|
| |
|
|
|
| |
Properly handle fastcomp wasm safe heap: emscripten_get_sbrk_ptr is an asm.js library function, which means it is inside the wasm after asm2wasm, and exported. Find it via the export.
|
| |
|
|
|
| |
To allow #2331 to roll, I forgot that upstream and fastcomp handle sbrk differently. This fixes that, and handles the upstream case where we import sbrk itself from JS.
We can simplify this after emscripten-core/emscripten#9397 lands, however, it may also be nice to keep the backwards compatibility for running on existing wasm files in the wild.
|
| |
|
| |
This helps with debugging human-readable sections like sourceMappingURL.
|
| |
|
|
|
|
|
| |
Currently emscripten links the wasm, then links the JS, then computes the final static allocations and in particular the location of the sbrk ptr (i.e. the location in memory of the brk location). Emscripten then imports that into the asm.js or wasm as env.DYNAMICTOP_PTR. However, this didn't work in the wasm backend where we didn't have support for importing globals from JS, so we implement sbrk in JS.
I am proposing that we change this model to allow us to write sbrk in C and compile it to wasm. To do so, that C code can import an extern C function, emscripten_get_sbrk_ptr(), which basically just returns that location. The PostEmscripten pass can even apply that value at compile time, so we avoid the function call, and end up in the optimal place, see #2325 and emscripten PRs will be opened once other stuff lands.
However, the SafeHeap pass must be updated to handle this, or our CI will break in the middle. This PR fixes that, basically making it check if env.DYNAMICTOP_PTR exists, or if not then looking for env.emscripten_get_sbrk_ptr, so that it can handle both.
|
| |
|
|
|
|
|
| |
We emitted the __wasm_memory_size function only when memory growth was enabled, but it can be used without that too.
In theory we could only emit it if either memory growth or memory.size is used, but I think we can expect JS minifiers to do that later.
Also fix a test suite bug - the check/auto_update script didn't run all the wasm2js tests when you run it with argument wasm2js (it used that as the list of tests, instead of the list of files, which confused me here for a while...).
|
| |
|
|
|
|
|
| |
(which is called DYNAMICTOP_PTR in emscripten) (#2325)
The assumption is that an import env.emscripten_get_sbrk_ptr exists, and we replace the value returned from there with a constant. (We can't do all this in wasm-emscripten-finalize, as it happens before the JS compiler runs, which can add more static allocations; we only know where the sbrk ptr is later in compilation.) This just replaces the import with a function returning the constant; inlining etc. can help more later.
By setting this at compile time we can reduce code size and avoid importing it at runtime, which makes us more compatible with wasi (less special imports).
|
| |
|
|
|
| |
Remove wasi, as only wasi_unstable makes sense. Also remove shared constant for wasi as we don't know yet if it'll be needed later.
|
| |
|
|
|
|
|
|
|
| |
Renames the SIMDBitselect class to SIMDTernary and adds the new
{f32x4,f64x2}.qfm{a,s} ternary instructions. Because the SIMDBitselect
class is no more, this is a backwards-incompatible change to the C
interface. The new instructions are not yet used in the fuzzer because
they are not yet implemented in V8.
The corresponding LLVM commit is https://reviews.llvm.org/rL370556.
|
| | |
|
| |
|
| |
This makes the minification pass aware of "wasi_unstable" and "wasi" as well.
|
| |
|
| |
See emscripten-core/emscripten#9206, the asyncify names can need complex escaping, so this provides an escape hatch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Emscripten's minifier mis-minifies a couple bits in the memory
init function that's used with wasm2js when not using an external
memory init file:
https://github.com/emscripten-core/emscripten/issues/8886
Previous fix worked around the bug in one place but failed to
account for another. Have now confirmed that it works with this
change in place.
Updated test cases to match.
|
| | |
|
| |
|
|
|
|
| |
This adds `-all` argument to wasm2js testing and fixes wasm2js to
actually take that argument (currently it doesn't, when it takes a wast
file). This also adds a wasm2js test for `atomic.fence` instruction that
was added in #2307.
|
| |
|
|
|
|
|
| |
This adds `atomic.fence` instruction:
https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#fence-operator
This also fix bugs in `atomic.wait` and `atomic.notify` instructions in
binaryen.js and adds tests for them.
|
| |
|
|
|
|
| |
It is not valid to defer the truncation of divisions because
accumulated non-integral results can produce different values when
they are combined before truncation. This was causing a test failure
in the Rust test suite.
|
| | |
|
| | |
|
