| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When translating a `try` expression, we may need an 'outer' block that
wraps the newly generated `try_table` so we can jump out of the
expression when an exception does not occur. (The condition we use is
when the `try` has any catches or if the `try` is a target of any
inner `try-delegate`s:
https://github.com/WebAssembly/binaryen/blob/219e668e87b012c0634043ed702534b8be31231f/src/passes/TranslateEH.cpp#L677)
In case the `try` has either of `catch` or `delegate`, when we have the
'outer' block, we add the newly created `try_table` in the 'outer' block
and replace the whole expression with the block:
https://github.com/WebAssembly/binaryen/blob/219e668e87b012c0634043ed702534b8be31231f/src/passes/TranslateEH.cpp#L670
https://github.com/WebAssembly/binaryen/blob/219e668e87b012c0634043ed702534b8be31231f/src/passes/TranslateEH.cpp#L332-L340
But in case of a catchless `try`, we forgot to do that:
https://github.com/WebAssembly/binaryen/blob/219e668e87b012c0634043ed702534b8be31231f/src/passes/TranslateEH.cpp#L388
So this PR fixes it.
|
| |
|
|
|
| |
All Struct/Array operations must ignore mutable fields in Precompute atm, which we
did, but StringNew has an array variant that does an effective ArrayGet operation,
which we didn't handle.
|
| |
|
|
|
|
|
|
|
| |
struct.new_with_default (#6523)
Before we preferred not to add default values, as that increases code size. But since
#6495 we turn more things into struct.new_with default, so it is important to handle
this. It seems likely that in most cases the code size downside of adding default
values is offset by avoiding a local.set later, so always do this (rather than add some
kind of heuristic).
|
| |
|
|
|
|
|
|
|
|
|
| |
hen the function return type is concrete, the translation result of a
`try`-`delegate` that targets the caller includes a `return` that
returns the whole function body:
https://github.com/WebAssembly/binaryen/blob/219e668e87b012c0634043ed702534b8be31231f/src/passes/TranslateEH.cpp#L751-L763
We should do that based on the function's return type, not the function
body's return type. The previous code didn't handle the case where the
function's return type is concrete but the function body's return type
is unreachable.
|
| |
|
|
|
|
|
| |
Since data and elem segments cannot be imported or exported, there is no way to
access them from the secondary module, so functions that need to refer to them
cannot be split out.
Fixes #6512.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR creates a pass to propagate debug location from parent node to child nodes which has no debug location with pre-order traversal. This is useful for compilers that use Binaryen API to generate WebAssembly modules.
It behaves like `wasm-opt` read text format file: children are tagged with the debug info of the parent, if they have no annotation of their own.
For compilers that use Binaryen API to generate WebAssembly modules, it is a bit redundant to add debugInfo for each expression, Especially when the compiler wrap expressions.
With this pass, compilers just need to add debugInfo for the parent node, which is more convenient.
For example:
```
(drop
(call $voidFunc)
)
```
Without this pass, if the compiler only adds debugInfo for the wrapped expression `drop`, the `call` expression has no corresponding source code mapping in DevTools debugging, which is obviously not user-friendly.
|
| |
|
|
|
|
|
| |
After the initial parsing pass to find the locations of all the module elements
and after the type definitions have been parsed, the next phase of parsing is to
visit all of the module elements and parse their types. This phase does not
require parsing function bodies, but it previously parsed entire functions
anyway for simplicity. To improve performance, skip that useless work.
|
| |
|
|
|
| |
The parsing of idchars was hot enough to show up while profiling the parsing of
a very large module. Optimize it to speed up the overall parse by about 16% in a
very unscientific measurement.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Creating an error in the parser is an extremely expensive operation for very
large files because it has to traverse the input buffer and count newlines to
compute the error message. Despite that, there are a few places were we create
errors just to discard them and continue parsing. The most notable of these
places was where we parsed the list of label index immediates for the br_table
instruction. The parser determined the end of the list by intercepting the error
produced when trying to parse one more label index.
Fix this significant performance problem causing parsing to be quadratic by
introducing and using `maybeLabelidx`, which tries to parse a label index but
does not produce an error if it fails.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Converts the following:
(some.operation
(ref.cast .. (local.tee $ref ..))
(local.get $ref)
)
into:
(some.operation
(local.tee $temp
(ref.cast .. (local.tee $ref ..))
)
(local.get $temp)
)
|
| |
|
|
|
| |
None of our tests exercised the --entry or --skip options in wasm-shell, and
since wasm-shell is probably not used for anything outside our testing, there's
no reason to keep them. Remove them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the standard text format, try scopes can be targeted by both normal branches
and delegates, but in Binaryen IR we only allow them to be targeted by
delegates, so we have to translate branches to try scopes into branches to
wrapper blocks instead. These wrapper blocks must have different names than the
try expressions they wrap, so we actually need to track two label names for try
expressions: one for delegates and another for normal branches.
We previously tried to avoid this complexity by tracking only the branch label
and computing the delegate label from the branch label as necessary, but that
produced unnecessary wrapper blocks and ugly label names that did not appear in
the source.
To produce better IR and minimize the diff when switching to the new text
parser, bite the bullet and track the delegate and branch label names
separately. This eliminates unnecessary wrapper blocks and keeps try names the
same as in the wat source where possible.
|
| |
|
|
| |
To reduce the size of the test output diff when switching to the new text
parser, update it to generate the same block names as the legacy parser.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously would eagerly drop all concretely typed expressions on the stack
when pushing an unreachable instruction. This was semantically correct and
closely modeled the semantics of unreachable instructions, which implicitly drop
the entire stack and start a new polymorphic stack. However, it also meant that
the structure of the parsed IR did not match the structure of the folded input,
which meant that tests involving unreachable children would not parse as
intended, preventing the test from testing the intended behavior.
For example, this wat:
```wasm
(i32.add
(i32.const 0)
(unreachable)
)
```
Would previously parse into this IR:
```wasm
(drop
(i32.const 0)
)
(i32.add
(unreachable)
(unreachable)
)
```
To fix this problem, we need to stop eagerly dropping stack values when
encountering an unreachable instruction so we can still pop expressions pushed
before the unreachable as direct children of later instructions. In the example
above, we need to keep the `i32.const 0` on the stack so it is available to be
popped and become a child of the `i32.add`.
However, the naive solution of simply popping past unreachables would produce
invalid IR in some cases. For example, consider this wat:
```wasm
f32.const 0
unreachable
i32.add
```
The naive solution would parse this wat into this IR:
```wasm
(i32.add
(f32.const 0)
(unreachable)
)
```
But we do not want to parse an `i32.add` with an `f32`-typed child. Neither do
we want to reject this input, since it is a perfectly valid Wasm fragment. In this
case, we actually want the old behavior of dropping the `f32.const` and
replacing it with another `unreachable` as the first child of the `i32.add`.
To both match the input structure where possible and also gracefully fall back
to the old behavior of dropping expressions prior to the unreachable, collect
constraints on the types of each child for each kind of expression and compare
them to the types of available expressions on the stack when an unreachable
instruction will be popped. When the constraints are satisfied, pop expressions
normally, even after popping the unreachable instruction. Otherwise, drop the
instructions that precede the unreachable instruction to ensure we parse valid
IR.
To collect the constraints, add a new `ChildTyper` utility that calls a
different callback for each kind of possible type constraint for each child. In
the future, this utility can be used to simplify the validator as well.
|
| |
|
|
|
|
|
|
|
|
|
| |
The code had a different workaround, namely to add a block with an explicit
type to avoid changing the type at all (i.e. the block declared the original
type of the thing we replaced, not the refined type). But by adding a block we
can end up with an invalid pop, as the fuzzer found, see the EH testcase here.
To fix this, use the usual workaround of just running ReFinalize. That is simpler
and also improves the code while we do it. It does add more work, but this is
likely a very rare situation anyhow.
|
| |
|
|
|
|
|
|
|
|
| |
For types that do not have explicit names, we generate index-based names in the
printer. However, we did not previously ensure that the generated types were not
already used as explicit names, so it was possible to print the same name for
multiple types, which is not valid.
Fix the problem by skipping indices that are already used as type names.
Fixes #6492.
|
| |
|
|
|
|
|
| |
Previously we chose the first with a proper type, and now we start to scan from
a random index, giving later functions a chance too, so we should be emitting a
greater variety of ref.func targets.
Also remove some obsolete fuzzer TODOs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
struct.new with default values can be struct.new_default.
array.new with default values can be array.new_default.
array.new of size 1 should be array.new_fixed (saves the Const).
array.new_fixed with default values can be array.new_default.
array.new_fixed with equal but non-default values can be array.new
(basically use a Const to say how many copies we want, rather than copy).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The latest idea for efficient string constants is to encode the constants in
the import names of their globals and implement fast paths in the engines for
materializing those constants at instantiation time without needing to parse
anything in JS. This strategy only works for valid strings (i.e. strings without
unpaired surrogates) because only valid strings can be used as import names in
the WebAssembly syntax.
Add a new configuration of the StringLowering pass that encodes valid string
contents in import names, falling back to the JSON custom section approach for
invalid strings.
To test this chang, update the printer to escape import and export names
properly and update the legacy parser to parse escapes in import and export
names properly. As a drive-by, remove the incorrect check in the parser that the
import module and base names are non-empty.
|
| |
|
|
|
|
|
|
|
| |
hasExplicitName. NFC (#6496)
This is temporary workaround for the current test failures on the
emscripten waterfall. The real fix I believe will be to make
`hasExplicitName` the default in these kinds of cases.
See: #6466
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OptimizeInstructions::areConsecutiveInputsEqual() (#6481)
"Generative" is what we call something like a struct.new that may be syntactically
identical to another struct.new, but each time a new value is generated. The same
is true for calls, which can do anything, including return a different value for
syntactically identical calls.
This was not a bug because the main user of isGenerative,
areConsecutiveInputsEqual(), was too weak to notice, that is, it gave up sooner,
for other reasons. This PR improves that function to do a much better check,
which makes the fix necessary to prevent regressions.
This is not terribly important for itself, but will help a later PR that will add code
that depends more heavily on areConsecutiveInputsEqual().
|
| | |
|
| |
|
|
|
|
|
| |
- Only write explicit function names.
- When merging modules, the name of types, globals and tags in all
modules but the first were lost.
- Set name as explicit when copying a function with a new name.
|
| |
|
|
|
|
|
| |
GUFA already truncated packed fields on write, which is enough for unsigned gets,
but for signed gets we also need to sign them on reads.
Similar to #6493 but for GUFA. Also found by #6486
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Heap2Local's (#6493)
CFP already had logic for truncating but not for sign-extending, which this
fixes.
Use the new helper function in Heap2Local as well. This changes the model
there from "truncate on set, sign-extend on get" to "truncate or sign-extend
on get". That is both simpler by reusing the same logic as CFP but also more
optimal: the idea to truncate on sets made sense since sets are rarer, but if
we must then sign-extend on gets then we can end up doing more work
overall (as the truncations on sets are not needed if all gets are signed).
Found by #6486
|
| |
|
|
|
|
|
| |
When we need to pop a tuple and the top value on the stack is unreachable, just
pop the unreachable rather than producing a tuple.make. This always produces
valid IR since an unreachable is always valid where a tuple would otherwise be
expected. It also avoids bloating the parsed IR, since we would previously parse
a `tuple.make` where all the children were unreachable in this case.
|
| |
|
|
|
|
| |
We previously printed the size of the tuple operand as the arity, but that
printed `1` when the operand is unreachable. We don't allow our text input to
use `1` as the arity, so don't print it, either. Instead, print the smallest
valid arity, `2`, in this case.
|
| | |
|
| |
|
|
|
|
| |
In #6480 I forgot that StructGet can be signed, which means we need to emit
a sign-extend.
Arrays already copied the field as part of Array2Struct.
|
| |
|
|
|
| |
Use the previous implementation when no return_call is in a try block. This
avoids moving code around (as a sibling of the caller body or the inlined body),
so that should allow more local optimizations after inlining.
|
| |
|
|
|
|
| |
Previously we did not optimize a struct or an array with a packed field. As a result a
single packed field in a struct prevented the entire struct from being localized,
which this fixes. This is also useful for arrays as packed arrays are common (e.g. for
string data).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To keep things simple, this adds a Array2Struct component to the pass. When we
find a non-escaping array, we run that to turn it into a struct, and then run the
existing Struct2Local to convert that to locals. This avoids refactoring Struct2Local
to handle both structs and arrays (with the downside of making the optimization of
arrays a little less efficient, but they are rarer, I suspect - that is certainly the case
in Java output I've seen).
The core EscapeAnalyzer logic is generalized to handle both arrays and structs,
but the changes there are thankfully quite minor.
|
| |
|
|
| |
#6457 added a test that exposed existing nondeterminism.
|
| |
|
|
| |
Treat them the same as returns and test that they can be folded out of try-catch
blocks because they do not have throws effects.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a combined commit covering multiple PRs fixing the handling of return
calls in different areas. The PRs are all landed as a single commit to ensure
internal consistency and avoid problems with bisection.
Original PR descriptions follow:
* Fix inlining of `return_call*` (#6448)
Previously we transformed return calls in inlined function bodies into normal
calls followed by branches out to the caller code. Similarly, when inlining a
`return_call` callsite, we simply added a `return` after the body inlined at the
callsite. These transformations would have been correct if the semantics of
return calls were to call and then return, but they are not correct for the
actual semantics of returning and then calling.
The previous implementation is observably incorrect for return calls inside try
blocks, where the previous implementation would run the inlined body within the
try block, but the proper semantics would be to run the inlined body outside the
try block.
Fix the problem by transforming inlined return calls to branches followed by
calls rather than as calls followed by branches. For the case of inlined return
call callsites, insert branches out of the original body of the caller and
inline the body of the callee as a sibling of the original caller body. For the
other case of return calls appearing in inlined bodies, translate the return
calls to branches out to calls inserted as siblings of the original inlined
body.
In both cases, it would have been convenient to use multivalue block return to
send call parameters along the branches to the calls, but unfortunately in our
IR that would have required tuple-typed scratch locals to unpack the tuple of
operands at the call sites. It is simpler to just use locals to propagate the
operands in the first place.
* Fix interpretation of `return_call*` (#6451)
We previously interpreted return calls as calls followed by returns, but that is
not correct both because it grows the size of the execution stack and because it
runs the called functions in the wrong context, which can be observable in the
case of exception handling.
Update the interpreter to handle return calls correctly by adding a new
`RETURN_CALL_FLOW` that behaves like a return, but carries the arguments and
reference to the return-callee rather than normal return values.
`callFunctionInternal` is updated to intercept this flow and call return-called
functions in a loop until a function returns with some other kind of flow.
Pull in the upstream spec tests return_call.wast, return_call_indirect.wast, and
return_call_ref.wast with light editing so that we parse and validate them
successfully.
* Handle return calls in wasm-ctor-eval (#6464)
When an evaluated export ends in a return call, continue evaluating the
return-called function. This requires propagating the parameters, handling the
case that the return-called function might be an import, and fixing up local
indices in case the final function has different parameters than the original
function.
* Update effects.h to handle return calls correctly (#6470)
As far as their surrounding code is concerned return calls are no different from
normal returns. It's only from a caller's perspective that a function containing
a return call also has the effects of the return-callee. To model this more
precisely in EffectAnalyzer, stash the throw effect of return-callees on the
side and only merge it in at the end when analyzing the effects of a full
function body.
|
| |
|
|
| |
Helps emscripten-core/emscripten#17380 by logging all the reasons why we
instrument a function, and not just the first as we did before.
|
| |
|
|
|
|
| |
Separate out an EscapeAnalyzer class that does the escape analysis,
and a Struct2Local one that does the optimization.
Also make a few things const here to be safer.
|
| |
|
| |
These were causing build failures on the Emscripten builder.
|
| |
|
|
|
|
|
|
| |
This PR is part of a series that adds basic support for the typed
continuations/wasmfx proposal.
This particular PR adds cont and nocont as top and bottom types for
continuation types, completely analogous to func and nofunc for function types
(also: exn and noexn).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the hard-coded generation of a switch and cases, and allows the user
to define the boilerplate at the start and end of the main output, and of what is
generated for each expression. By default we still emit a switch and cases.
Also standardize the output by never emitting ; unnecessarily, which we were
inconsistent about.
This serves two goals: First, it will make using embind on Binaryen simpler as
embind needs to generate C++ template logic for each expression, and not a
switch (and we cannot have extra ; in embind notation). Second, this makes
the format much simple to parse, which is a stepping stone for #6460, e.g.
before we had
case Expression::Id::LoopId: {
DELEGATE_START(Loop);
DELEGATE_FIELD_CHILD(Loop, body);
DELEGATE_FIELD_SCOPE_NAME_DEF(Loop, name);
DELEGATE_END(Loop);
break;
}
and now we have
DELEGATE_FIELD_CASE_START(Loop)
DELEGATE_FIELD_CHILD(Loop, body)
DELEGATE_FIELD_SCOPE_NAME_DEF(Loop, name)
DELEGATE_FIELD_CASE_END(Loop)
The main part of this diff was autogenerated by this python:
for l in x.splitlines():
if l.startswith(' case'):
id = l.split(':')[4][:-2]
print(f'DELEGATE_FIELD_CASE_START({id})')
if l.startswith(' DELEGATE_FIELD'):
print(l)
if l.startswith(' DELEGATE_END'):
id = l[17:-2]
print(f'DELEGATE_FIELD_CASE_END({id})')
print()
|
| |
|
|
| |
- Output segment names even when no memory is declared.
- Only write explicit names.
|
| |
|
|
|
| |
The new asyncify flag --pass-arg=asyncify-propagate-addlist changes the
behavior of --pass-arg=asyncify-addlist : with it, callers of functions in the
asyncify-addlist will be also instrumented.
|
| |
|
|
| |
the start (#6459)
|
| |
|
|
|
|
|
|
|
| |
For a global we store the name and a type, and the type may
be more precise than the global's type in the wasm. As a
result, when hashing, it is not enough to hash only the name, so hash
the type as well.
Also add a random TODO as a comment.
|
| |
|
|
|
| |
Found by the fuzzer. We already processed the work queue in a deterministic
order, but the roots were unordered. The work queue's initial state is filled by
the roots, so we must process the roots deterministically as well.
|
| |
|
|
|
|
|
| |
To avoid slow-running fuzz cases, we report a host limit when interpreting
atomic.wait with any non-zero timeout. However, in the allowed case where the
timeout is zero, we were incorrectly interpreting the wait as returning 0,
meaning that it was woken up, instead of 2, meaning that the timeout expired.
Fix it to return 2.
|
| |
|
|
|
|
|
|
| |
The implementation of calls with this option was incorrect because it cleared
the locals before evaluating the call arguments. The likely explanation for why
this was never noticed is that there are no users of this option, especially
since it is exposed in the C and JS APIs but not used internally.
Rather than try to fix the implementation, just remove the option.
|
| | |
|
| | |
|
