| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes: #3226
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I believe originally wasm did not allow overlapping segments, that is, where
one memory segment tramples the data from a previous one. But then the
spec changed its mind and we allowed it. Binaryen seems to have assumed
the original case, and not checked for trampling.
If there is a chance of trampling, we cannot optimize out zeros - the zero
may have an effect if it tramples data from a previous segment. This does
not occur in practice in LLVM output, which is why this wasn't a problem
so far, I think.
An existing testcase hit this issue, so I split it up.
|
|
|
|
| |
We can't validate or print out the wasm in that case, but at least
logging the names as they run can help debug some situations.
|
|
|
|
|
|
|
|
|
| |
The s-parser was assigning numbers names per-type where as
the binaryn reader was using the global import count as the
number to append.
This change switches to use per-element count which I think
it preferable as it increases the stability of the auto-generated
names. e.g. memory is now always named `$mimport0`.
|
|
|
|
|
|
|
|
|
|
|
| |
This PR fixes a bug in which the segment index of a memory.init instruction was
incorrect in some circumstances. Specifically, the first segment index used in
output memory.init instructions was always the index of the first segment
created from splitting up the corresponding input segment. This was incorrect
when the input memory.init had an offset that caused it to skip over that first
emitted segment so that the first output memory.init should have referred to a
subsequent output segment.
Fixes #3225.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
According to the WebAssembly spec, Wasm is an abbreviation, not an acronym.
|
|
|
|
|
|
|
|
| |
`(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`
|
|
|
|
|
| |
growMemory() now also returns whether we succeeded.
Without this it could eventually start to swap etc., which is annoying.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
Mentioning if it's a memory or a table segment is convenient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
When there are two versions of a function, one handling tuples and the other handling non-tuple values, the previous naming convention was to have "Single" in the name of the non-tuple handling function. This PR simplifies the convention and shortens function names by making the names plural for the tuple-handling version and singular for the non-tuple-handling version.
|
|
|
|
|
|
|
| |
fixLabels() in the fuzzer looks for invalid labels and fixes them up,
after doing some random changes to existing wasm (which checks
for types while doing so, but it may invalidate labels if we remove the
target of a branch, for example). This adds trivial support for
BrOnExn and Try there.
|
|
|
|
|
|
|
| |
Previously getLoggableType would allocate a vector every time. This
caches it.
Also add isLoggableType which will need this caching as I will be
calling it quite a lot in a future patch to the fuzzer.
|
| |
|
|
|
|
| |
The replaceFunctions utility replaced exports by name, but did not check
the kind, so it could get confused when names happen to overlap.
|
| |
|
|
|
| |
See emscripten-core/emscripten#11860
|
|
|
|
|
|
| |
Wasm turned out to not be that good for a DSL for such peephole optimizations,
so that never made progress. Meanwhile we have the new matcher stuff which
works well.
|
|
|
| |
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.
|
|
|
| |
For consistency with `makeFromInt32`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Use overloads instead of templates where applicable and change function names
from PascalCase to camelCase. Also puts the functions in the Bits namespace to
avoid naming conflicts.
|
|
|
| |
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.
|
|
|
| |
Comparing and hashing literals previously depended on `getBits`, which was fine while there were only basic numeric types, but doesn't map well to reference types anymore. Hence this change limits the use of `getBits` to basic numeric types, and implements reference types-aware comparisons and hashing do deal with the newer types.
|