| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
wasm-ld now does this better than binaryen and does
it by default when linking and executable and optionally
with `-Bsymbolic` when linking a shared library.
See https://reviews.llvm.org/D89152
|
|
|
|
| |
This pass will convert a module with 64-bit loads and stores accessing a 64-bit memory to a regular 32-bit one.
Pointers remain 64-bit but are truncated just before use.
|
|
|
|
|
|
|
|
| |
`(uint32_t)x / C` --> `x >= C`, where `C > 2^31`
`(uint32_t)x / -1` --> `x != -1`
and for `shrinkLevel == 0`:
`(uint64_t)x / C` --> `uint64_t(x >= C)`, where `C > 2^63`
`(uint64_t)x / -1` --> `x != -1`
|
| |
|
|
|
|
|
|
|
|
|
| |
That global is for internal use. If we emit random sets to it, we could prevent
it from doing its job of preventing an infinite loop (normally it decreases each
time a loop runs or we recurse, until we reach 0 - if we set it to a nonzero
value in that code, that would be bad).
Random gets are less of a problem, but may be confusing when debugging
a testcase.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(#3220)
We turn a br_table with a single target into a br, but we reverse the order of the
condition and the value when doing so, which we forgot to take into account.
|
|
|
|
|
|
| |
Generated by running:
./scripts/test/generate_lld_tests.py
./auto_update_tests.py
|
| |
|
|
|
|
| |
The replaceFunctions utility replaced exports by name, but did not check
the kind, so it could get confused when names happen to overlap.
|
|
|
| |
Specifically, truncates constant shift values that are greater than the number of bits available and optimizes out explicit masking of the shift value that is redundant with the implicit masking performed by shift operations.
|
|
|
| |
`(signed)x % (i32|i64).min_s ==> (x & (i32|i64).max_s)` is not valid unless compared to zero.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a more general (additional) version of #3153 which also handles negative constant divisors:
`(int32)x % -4 == 0` --> `(x & 3) == 0`
`x % -C_pot == 0` --> `(x & (abs(C_pot) - 1)) == 0`
and special two-complement values as well:
`(int32)x % 0x80000000 == 0` --> `(x & 0x7fffffff) == 0`
`(int64)x % 0x8000000000000000 == 0` --> `(x & 0x7fffffffffffffff) == 0`
as separete rules:
`(int32)x % 0x80000000` --> `x & 0x7fffffff`
`(int64)x % 0x8000000000000000` --> `x & 0x7fffffffffffffff`
The [previous pr](https://github.com/WebAssembly/binaryen/pull/3153) didn't use these possibilities.
|
|
|
|
|
|
|
|
|
|
|
|
| |
(found by the fuzzer)
It is not valid to replace x | (y | x) ==> y | x, if x, y cannot be reordered.
It is also not valid to replace x ^ (y ^ x) ==> y, if x, y cannot be reordered,
for a more subtle reason: if they cannot be reordered then y can affect the
value of x (the opposite is not possible as we checked x for side effects so
that we could remove one copy). If so, then the second appearance of x
could be different, if e.g. it reads a local y writes to. Whereas, if it's ok to
reorder, then it's ok to do x ^ (y ^ x) ==> x ^ (x ^ y) ==> y.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
mask (#3184)
|
|
|
| |
This depends on https://github.com/emscripten-core/emscripten/pull/12391
|
|
|
| |
Adds `BinaryenGetFastMath` and `BinaryenSetFastMath` to the C API, respectively `binaryen.getFastMath` and `binaryen.setFastMath` to the JS API.
|
|
|
|
|
|
|
|
|
|
| |
This will allow for the completely removal of
`__growWasmMemory` as a followup. We currently
unconditionally generate this function
in `generateMemoryGrowthFunction`.
See #3180
|
|
|
|
| |
This updates lld tests by running generate_lld_tests.py with the latest
toolchain.
|
|
|
| |
It's not an actual constructor, just a JS function that returns the object.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to clang and gcc, --fast-math makes us ignore corner cases of floating-point
math like NaN changes and (not done yet) lack of associativity and so forth.
In the future we may want to have separate fast math flags for each specific thing,
like gcc and clang do.
This undoes some changes (#2958 and #3096) where we assumed it was
ok to not change NaN bits, but @binji corrected us. We can only do such things in fast
math mode. This puts those optimizations behind that flag, adds tests for it, and
restores the interpreter to the simpler code from before with no special cases.
|
|
|
| |
Specifically, when `x` has at most 32 bits so that wrapping doesn't change its value.
|
|
|
|
|
|
| |
Specifically when the divisor is a power of two.
`eqz((signed)x % C_pot)` -> `eqz(x & (C_pot - 1))`
`(signed)x % C_pot != 0` -> `x & (C_pot - 1) != 0`
|
|
|
| |
SExpressionWasmBuilder was not applying default memory and table import names on the memory and table, unlike on functions, globals and events, where it applies them. Also aligns default import names to use the same shorter forms as in binary parsing.
|
|
|
| |
NFC, except adding most of the boilerplate for the remaining GC instructions. Each implementation site is marked with a respective `TODO (gc): theInstruction` in between the typical boilerplate code.
|
| |
|
|
|
| |
Integrates `i31ref` types and instructions into the fuzzer, by assuming that `(i31.new (i32.const N))` is constant and hence suitable to be used in global initializers.
|
|
|
| |
Implements the parts of the Extended Name Section Proposal that are trivially applicable to Binaryen, in particular table, memory and global names. Does not yet implement label, type, elem and data names.
|
|
|
| |
details: https://github.com/WebAssembly/binaryen/issues/3149
|
|
|
| |
This can unlock further instruction optimizations that do not apply to signed operations.
|
|
|
|
|
| |
In that case LLVM emits the address of the declarations area (where locals are
declared) of the function, which is even earlier than the instructions actual
first byte. I'm not sure why it does this, but it's easy to handle.
|
|
|
|
| |
This relaxation has made it to Chrome stable, so it makes sense that we would
allow it in the tools.
|
|
|
|
|
| |
Adds new matchers that allow for matching any unary or binary operation and
optionally extracting it. The previous matchers only allowed matching specific
unary and binary operations. This should help simplify #3132.
|
|
|
|
|
| |
Also, format the asmFunc call to make it more readable in the ES6
modules case.
|
|
|
| |
Adds the `i31.new` and `i31.get_s/u` instructions for creating and working with `i31ref` typed values. Does not include fuzzer integration just yet because the fuzzer expects that trivial values it creates are suitable in global initializers, which is not the case for trivial `i31ref` expressions.
|
|
|
|
|
| |
PostEmscripten (#3161)
These were removed completely from the emscripten side in #12057
|
|
|
|
|
|
| |
Apparently I misunderstood the DWARF spec on this. Abbreviation offsets are all
relative to 1 (as 0 is not a valid number). For some reason I thought the first DIE's
index was the "base", as in practice LLVM always emits the lowest index there,
and that's what the LLVM YAML code suggested to me.
|
|
|
|
| |
We did so earlier sometimes, as we would pick 0 and then tweak it with
a negation. But that favored positive 0. This makes coverage symmetric.
|
|
|
|
|
|
|
|
|
|
|
|
| |
These test output files are ignored and so contain stale output
that is neither checked during `check.py` not updated during
`auto_update_tests.py`.
There are three clases to tests here:
1. Spec tests that end in 64.wast are ignored by scripts/test/wasm2js.py
2. Spec tests that are globallyi ignoed by shared.py:SPEC_TESTS_TO_SKIP
3. hello_world.2asm.js.. I cant tell where this came remove it seems
like an anomaly.
|
| |
|
| |
|
|
|
| |
With `eqref` now integrated, the `ref.eq` instruction can be implemented. The only valid LHS and RHS value is `(ref.null eq)` for now, but implementation and fuzzer integration is otherwise complete.
|
|
|
| |
Adds the `eqref` and `i31ref` types to their respective code locations. Implements what can be implemented trivially and otherwise traps with a TODO for now. Integration of `eqref` is mostly complete due to it being nullable, just like `anyref`, but `i31ref` needs to remain disabled in the fuzzer because we are lacking the functionality to create trivial `i31ref` values, i.e. `(i31.new (i32.const 0))`, which is left for follow-ups to implement.
|
|
|
|
|
|
|
|
|
|
|
| |
Provides an easily extensible layered API for matching expression patterns and
extracting their components. The low-level API provides modular building blocks
for creating matchers for any data type and the high-level API provides a
succinct and flexible interface for matching expressions and extracting useful
information from them.
Matchers are currently provided for Const, Unary, Binary, and Select
instructions. Adding a matcher for a new type of expression is straightforward
enough that I expect to add them as they become useful as part of other changes.
|
|
|
| |
Also includes a lot of new spec tests that eventually need to go into the spec repo
|
|
|
| |
Updates the JS API `Function` wrapper introduced in #3115 with bindings for more C API functions. Also adds additional comments to describe the inner workings of wrappers in more detail.
|