| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
If a global is marked mutable but not assigned to, make it immutable.
If an immutable global is a copy of another, use the original, so we can remove the duplicates.
Fixes #2011
|
|
|
| |
Applies the changes in #2065, and temprarily disables the hook since it's too slow to run on a change this large. We should re-enable it in a later commit.
|
|
|
|
| |
EmscriptenGlueGenerator::separateDataSegments (#2068)
|
|
|
| |
Mass change to apply clang-format to everything. We are applying this in a PR by me so the (git) blame is all mine ;) but @aheejin did all the work to get clang-format set up and all the manual work to tidy up some things to make the output nicer in #2048
|
|
|
|
|
| |
As well as i64 splitting this pass was also converting f32 to f64
at the wasm boundry. However it appears this is not actually useful
and makes somethings (such as dynamic linking) harder.
|
|
|
|
|
|
|
| |
Implement interpretation of remaining bulk memory ops, add bulk memory
spec tests with light modifications, fix bugs preventing the fuzzer
from running correctly with bulk memory, and fix bugs found by the
fuzzer.
|
|
|
|
|
|
|
|
|
| |
When replacing the first argument to an asm call, allow more complex
expressions for expressing the address.
This fixes the case where the first argument might be the result
of adding a constant to __memory_base.
|
|
|
|
|
|
| |
This reverts commit cb2d63586c08a3dd194d2b733ceb3f5051c081f8.
The issues with feature validation were mostly resolved in #1993, and
this PR finishes the job by adding feature flags to wasm-as to avoid
emitting the DataCount section when bulk-memory is not enabled.
|
|
|
| |
Split them into two i32 globals.
|
|
|
|
|
| |
In the absence of the target features section or command line flags. When there are command line flags, it is an error if they do not exactly match the target features section, except if --detect-features has been provided.
Also adds a --print-features pass to print the command line flags for all enabled options and uses it to make the feature tests more rigorous.
|
|
|
|
|
|
|
|
| |
Previously we were searching for the function by name but this
doesn't work when the internal name for the function is different.
In order to repro such a case the shared.c test was converted to C++
since then binaryen's internal name is different since it comes from
the de-mangled name section.
|
|
|
|
|
| |
Its presence was causing validation errors in the Emscripten test
suite. This should be reverted once the default feature set is no
longer All.
|
|
|
|
|
|
|
|
| |
* DataCount section
Read the DataCount section and verify that it agrees with the data
section. Also emit the DataCount section when bulk-memory is enabled
and there are a nonzero number of segments. Factor out some shared
unit test code.
|
|
|
|
|
| |
This allows us to emit a (potentially modified) target features
section and conditionally emit other sections such as the DataCount
section based on the presence of features.
|
|
|
|
|
|
| |
In relocatable code the constant offset might be relative to
__memory_base.
|
|
|
|
|
|
|
|
| |
Hash the contents of all of memory and log that out in random places in the fuzzer, so we are more sensitive there and can catch memory bugs.
Fix UB that was uncovered by this in the binary writing code - if a segment is empty, we should not look at &vector[0], and instead use vector.data().
Add Builder::addExport convenience method.
|
|
|
|
|
|
|
|
| |
Turns out there was already a precedent in emscripten for using
`fp$` for these functions.
Also, improve the heuristics for guessing the stack pointer global.
There are cases where we don't use have an explicit stack pointer at
all but *do* have both imported and exported globals.
|
|
|
|
|
|
| |
It was previously part of writing a binary, but changing the number of
segments at such a late stage would not work in the presence of bulk
memory's datacount section. Also updates the memory packing pass
to respect the web's limits on the number of data segments.
|
|
|
|
|
| |
Adds support for the bulk memory proposal's passive segments. Uses a
new (data passive ...) s-expression syntax to mark sections as
passive.
|
| |
|
|
|
| |
Emscripten runs wasm-emscripten-finalize before running wasm-opt, so the target features section is stripped out before optimizations are run. One option would have been to add another wasm-opt invocation at the very end to strip the target features section, but dumping the features as metadata avoids the extra tool invocation. In the long run, it would be nice to have only as single binaryen invocation to do all the work that needs doing.
|
|
|
|
|
|
| |
This key is used by emscripten when building with MAIN_MODULE in order
to export global variables from the main module to the side modules.
|
|
|
|
|
|
|
| |
If the user does not supply features explicitly on the command line,
read and use the features in the target features section for
validation and passes. If the user does supply features explicitly,
error if they are not a superset of the features marked as used in the
target features section and the user does not explicitly handle this.
|
|
|
|
|
|
|
| |
Minus multi-memory which we don't support yet.
Improve validator.
Fix some minor validation issues in our tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert PIC code generated by llvm to work with the current emscripten
ABI for dynamic linking:
- Convert mutable global imports from GOT.mem and GOT.func into
internal globals.
- Initialize these globals on started up in g$foo and f$foo imported functions
to calculate addresses at runtime.
Also:
- Add a test case for linking and finalizing a shared library
- Allow __stack_pointer global to be non-existent as can be case for
a shared library.
- Allow __stack_pointer global to be an import, as can be the case for
a shared library.
|
|
|
|
|
|
|
|
| |
This renames the following:
- `i32.wait` -> `i32.atomic.wait`
- `i64.wait` -> `i64.atomic.wait`
- `wake` -> `atomic.notify`
to match the spec.
|
|
|
| |
Not an actual problem, but hits an assertion in D_GLIBCXX_DEBUG, and is likely UB.
|
| |
|
|
|
|
|
| |
Moves the feature validation unit test file to a new directory,
'unit', and adds new tests for SIMD and sign-ext. Adds validation for
v128 globals and v128.const.
|
|
|
|
|
| |
Parse the formats allowed by the spec proposal and emit the i32x4
canonical format.
|
|
|
|
|
|
| |
Refactors features into a new wasm-features.h file and updates the
validator to check that all types are allowed. Currently this is only
relevant for the v128 SIMD type, but new types will be added in the
future. The test for this change is in #1948.
|
|
|
|
| |
This is necessary to write tests that don't require temporary files,
such as in #1948, and is generally useful.
|
|
|
| |
And run it in wasm-emscripten-finalize. This will prevent the emscripten output from changing when the target features section lands in LLVM.
|
|
|
|
|
|
|
|
|
| |
(#1944)
We expect the stack pointer to be of a certain type. This fixes
a segfault we are seeing when passed a binary which doesn't quite
meet our expectations.
|
|
|
|
| |
We now implement addFunction by creating a wasm module to wrap
that JS function and simply adding it to the table.
|
|
|
|
|
| |
This can happen in emscripten if we run fpcast-emu after previous passes created dynCalls already. If so, it's fine to just do nothing.
Fixes emscripten-core/emscripten#8229
|
|
|
|
|
|
|
|
| |
This PR changes the formatting of v128.const literals in text format / stack ir like so
- v128.const i32 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xa 0xb 0xc 0xd 0xe 0xf 0x80
+ v128.const i32 0x04030201 0x08070605 0x0c0b0a09 0x800f0e0d
Recently hit this when trying to load Binaryen generated text format with WABT, which errored with `error: unexpected token 0x5, expected ).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See #1919 - we did not do this consistently before.
This adds a lowMemoryUnused option to PassOptions. It can be passed on the commandline with --low-memory-unused. If enabled, we run the new optimize-added-constants pass, which does the real work here, replacing older code in post-emscripten.
Aside from running at the proper time (unlike the old pass, see #1919), this also has a -propagate mode, which can do stuff like this:
y = x + 10
[..]
load(y)
[..]
load(y)
=>
y = x + 10
[..]
load(x, offset=10)
[..]
load(x, offset=10)
That is, it can propagate such offsets to the loads/stores. This pattern is common in big interpreter loops, where the pointers are offsets into a big struct of state.
The pass does this propagation by using a new feature of LocalGraph, which can verify which locals are in SSA mode. Binaryen IR is not SSA (intentionally, since it's a later IR), but if a local only has a single set for all gets, that means that local is in such a state, and can be optimized. The tricky thing is that all locals are initialized to zero, so there are at minimum two sets. But if we verify that the real set dominates all the gets, then the zero initialization cannot reach them, and we are safe.
This PR also makes safe-heap aware of lowMemoryUnused. If so, we check for not just an access of 0, but the range 0-1023.
This makes zlib 5% faster, with either the wasm backend or asm2wasm. It also makes it 0.5% smaller. Also helps sqlite (1.5% faster) and lua (1% faster)
|
|
|
|
|
|
| |
Fixes #1921
Signed-off-by: Bogdan Vaneev <warchantua@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
* make DE_NAN avoid creating nan literals in the first place
* add a reducer option `--denan` to not introduce nans in destructive reduction
* add a `Literal::isNaN()` method
* also remove the default exception logging from the fuzzer js glue, which is a source of non-useful VM differences (like nan nondeterminism)
* added an option `--no-fuzz-nans` to make it easy to avoid nans when fuzzing (without hacking the source and recompiling).
Background: trying to get fuzzing on jsc working despite this open issue: https://bugs.webkit.org/show_bug.cgi?id=175691
|
|
|
| |
Fixes #1900
|
|
|
|
|
| |
We should emit a file with only the data segments, starting from the global base, and not starting from zero (the data before is unneeded, and the emscripten loading code assumes it isn't there).
Also fix the auto updater to work properly on .mem test updating.
|
|
|
|
|
| |
(#1894)
Fixes #1893
|
|
|
|
|
|
| |
Bulk memory operations
The only parts missing are the interpreter implementation
and spec tests.
|
|
|
|
|
|
|
|
| |
WebAssembly/tool-conventions#93 has a summary of emscripten's current thinking on this. For Binaryen, we don't want to do anything to the producers section by default, but do want it to be possible to optionally remove it. To achieve that, this PR
* creates a --strip-producers pass that removes that section.
* creates a --strip-debug pass that removes debug info, same as the old --strip, which is still around but deprecated.
A followup in emscripten will use this pass by default.
|
|
|
| |
Before this, we just did not emit illegal dynCalls. This was wrong as we do need them (e.g. if a function with a setjmp call calls a function with an i64 param - we'll have an invoke with that signature there). We just need to legalize them. This fixes that by first emitting them, and second by running legalization late, after dynCalls have been generated, so it legalizes them too.
|
|
|
|
|
|
|
| |
See emscripten-core/emscripten#7928 - we have been optimizing all wasms until now, and noticed this when the wasm object file path did not do so. When not optimizing, our methods of handling EM_ASM and EM_JS fail since the patterns are different.
Specifically, for EM_ASM we hunt for emscripten_asm_const(X, where X is a constant, but without opts it may be a get of a local. For EM_JS, the function body may not just contain a const, but a block with a set of the const and a return of a get later.
This adds logic to track gets and sets in basic blocks, which is sufficient to handle this.
|
|
|
| |
fixes bug reported in comment on e63c4a7 , #1885 (comment) , #1879 (comment)
|
|
|
|
|
| |
* Also fixes some bugs in wasm2js tests that did not validate.
* Rename FeatureOptions => ToolOptions, as they now contain all the basic stuff each tool needs for commandline options (validation yes or no, and which features if so).
|