| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Reverts #4889
The spec is unclear on this, and that PR moved us to do what V8 does. But
it sounds like we should clarify the spec to do things the other way, so this
goes back to that.
|
|
|
|
|
|
|
| |
For now this index is always 0, but we must emit it.
Also clean up the wat test a little - we don't have validation yet, but we should
not validate without a memory in that file.
|
|
|
|
|
|
| |
This starts to matter with strings, it turns out. This change should make us
runnable in v8.
Spec: https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md#instructions-1
|
|
|
|
|
|
|
| |
RTTs were removed from the GC spec and if they are added back in in the future,
they will be heap types rather than value types as in our implementation.
Updating our implementation to have RTTs be heap types would have been more work
than deleting them for questionable benefit since we don't know how long it will
be before they are specced again.
|
| |
|
|
|
|
|
|
|
|
|
| |
Basic reference types like `Type::funcref`, `Type::anyref`, etc. made it easy to
accidentally forget to handle reference types with the same basic HeapTypes but
the opposite nullability. In principle there is nothing special about the types
with shorthands except in the binary and text formats. Removing these shorthands
from the internal type representation by removing all basic reference types
makes some code more complicated locally, but simplifies code globally and
encourages properly handling both nullable and non-nullable reference types.
|
| |
|
|
|
|
| |
This measures the length of a view, so it seems simplest to make it a
sub-operation of the existing measure instruction.
|
|
|
|
|
|
|
| |
Unfortunately one slice is the same as python [start:end], using 2 params,
and the other slice is one param, [CURR:CURR+num] (where CURR is implied
by the current state in the iter). So we can't use a single class here. Perhaps
a different name would be good, like slice vs substring (like JS does), but
I picked names to match the current spec.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This implements it as a StringMeasure opcode. They do have the same number of
operands, same trapping behavior, and same return type. They both get a string and
do some inspection of it to return an i32. Perhaps the name could be StringInspect
or something like that, rather than StringMeasure..? But I think for now this might be
good enough, and the spec may change anyhow later.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Grouping all references together makes it easier for baseline compilers to
zero out memory (as the zeroing out may be different for MVP types vs.
references).
This puts all references together, either at the start or the end. As a
heuristic for that we see if the first local is a reference. As the optimizer
will sort locals by frequency, this ensures that the most-frequent local
stays in index 0.
Fixes #4773. See more details there
|
| |
|
|
|
|
|
| |
This is more work than a typical instruction because it also adds a new section:
all the (string.const "foo") strings are put in a new "strings" section in the binary, and
the instructions refer to them by index.
|
|
|
|
|
|
| |
This is the first instruction from the Strings proposal.
This includes everything but interpreter support.
|
|
|
|
|
| |
Update the opcodes for all relaxed SIMD instructions and remove the unsigned dot
product instructions that are no longer in the proposal.
|
|
|
|
|
|
| |
This unsafe experimental instruction is semantically equivalent to
ref.cast_static, but V8 will unsafely turn it into a nop. This is meant to help
us measure cast overhead more precisely than we can by globally turning all
casts into nops.
|
|
|
|
|
|
| |
Remove `Type::externref` and `HeapType::ext` and replace them with uses of
anyref and any, respectively, now that we have unified these types in the GC
proposal. For backwards compatibility, continue to parse `extern` and
`externref` and maintain their relevant C API functions.
|
|
|
| |
As proposed in https://github.com/WebAssembly/relaxed-simd/issues/52.
|
|
|
|
| |
Other opcode ends with `Inxm` or `Fnxm` (where n and m are integers),
while `i8x16.swizzle`'s opcode name doesn't have an `I` in there.
|
|
|
| |
As proposed in https://github.com/WebAssembly/relaxed-simd/issues/40.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With nominal function types, this change makes it so that we preserve the
identity of the function type used with call_indirect instructions rather than
recreating a function heap type, which may or may not be the same as the
originally parsed heap type, from the function signature during module writing.
This will simplify the type system implementation by removing the need to store
a "canonical" nominal heap type for each unique signature. We previously
depended on those canonical types to avoid creating multiple duplicate function
types during module writing, but now we aren't creating any new function types
at all.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds relaxed-simd instructions based on the current status of the
proposal
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md.
Binary opcodes are based on what is listed in
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md#binary-format.
Text names are not fixed yet, and some sort sort of names that maps to
the non-relaxed versions are chosen for this prototype.
Support for these instructions have been added to LLVM via builtins,
adding support here will allow Emscripten to successfully compile files
that use those builtins.
Interpreter support has also been added, and they delegate to the
non-relaxed versions of the instructions.
Most instructions are implemented in the interpreter the same way as the non-relaxed
simd128 instructions, except for fma/fms, which is always fused.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
See #4220 - this lets us handle the common case for now of simply having
an identical heap type to the table when the signature is identical.
With this PR, #4207's optimization of call_ref + table.get into
call_indirect now leads to a binary that works in V8 in nominal mode.
|
| |
|
|
|
|
| |
Adds the part of the spec test suite that this passes (without table.set we
can't do it all).
|
|
|
|
|
|
|
|
|
| |
See #4149
This modifies the test added in #4163 which used static casts on
dynamically-created structs and arrays. That was technically not
valid (as we won't want users to "mix" the two forms). This makes that
test 100% static, which both fixes the test and gives test coverage
to the new instructions added here.
|
|
|
|
|
|
|
|
|
|
|
|
| |
These variants take a HeapType that is the type we intend to cast to,
and do not take an RTT.
These are intended to be more statically optimizable. For now though
this PR just implements the minimum to get them parsing and to get
through the optimizer without crashing.
Spec: https://docs.google.com/document/d/1afthjsL_B9UaMqCA5ekgVmOm75BVFu6duHNsN9-gnXw/edit#
See #4149
|
|
|
|
|
|
|
| |
array.init is like array.new_with_rtt except that it takes
as arguments the values to initialize the array with (as opposed to
a size and an optional initial value).
Spec: https://docs.google.com/document/d/1afthjsL_B9UaMqCA5ekgVmOm75BVFu6duHNsN9-gnXw/edit#
|
|
|
|
|
|
|
|
|
|
|
| |
We recently decided to change 'event' to 'tag', and to 'event section'
to 'tag section', out of the rationale that the section contains a
generalized tag that references a type, which may be used for something
other than exceptions, and the name 'event' can be confusing in the web
context.
See
- https://github.com/WebAssembly/exception-handling/issues/159#issuecomment-857910130
- https://github.com/WebAssembly/exception-handling/pull/161
|
|
|
|
|
|
|
|
|
|
| |
This is the same as rtt.sub, but creates a "new" rtt each time. See
https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit#
The old Literal implementation of rtts becomes a little more complex here,
as it was designed for the original spec where only structure matters. It may
be worth a complete redesign there, but for now as the spec is in flux I think
the approach here is good enough.
|
|
|
|
|
|
| |
They are basically the flip versions. The only interesting part in the impl is that their
returned typed and sent types are different.
Spec: https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit
|
|
|
|
|
|
|
|
| |
Spec for it is here:
https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit#
Also reorder some things in wasm.h that were not in the canonical order (that has
no effect, but it is confusing to read).
|
|
|
|
|
|
|
|
|
| |
Renames the SIMD instructions
* LoadExtSVec8x8ToVecI16x8 -> Load8x8SVec128
* LoadExtUVec8x8ToVecI16x8 -> Load8x8UVec128
* LoadExtSVec16x4ToVecI32x4 -> Load16x4SVec128
* LoadExtUVec16x4ToVecI32x4 -> Load16x4UVec128
* LoadExtSVec32x2ToVecI64x2 -> Load32x2SVec128
* LoadExtUVec32x2ToVecI64x2 -> Load32x2UVec128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updates binary constants of SIMD instructions to match new opcodes:
* I16x8LoadExtSVec8x8 -> V128Load8x8S
* I16x8LoadExtUVec8x8 -> V128Load8x8U
* I32x4LoadExtSVec16x4 -> V128Load16x4S
* I32x4LoadExtUVec16x4 -> V128Load16x4U
* I64x2LoadExtSVec32x2 -> V128Load32x2S
* I64x2LoadExtUVec32x2 -> V128Load32x2U
* V8x16LoadSplat -> V128Load8Splat
* V16x8LoadSplat -> V128Load16Splat
* V32x4LoadSplat -> V128Load32Splat
* V64x2LoadSplat -> V128Load64Splat
* V8x16Shuffle -> I8x16Shuffle
* V8x16Swizzle -> I8x16Swizzle
* V128AndNot -> V128Andnot
* F32x4DemoteZeroF64x2 -> F32x4DemoteF64x2Zero
* I8x16NarrowSI16x8 -> I8x16NarrowI16x8S
* I8x16NarrowUI16x8 -> I8x16NarrowI16x8U
* I16x8ExtAddPairWiseSI8x16 -> I16x8ExtaddPairwiseI8x16S
* I16x8ExtAddPairWiseUI8x16 -> I16x8ExtaddPairwiseI8x16U
* I32x4ExtAddPairWiseSI16x8 -> I32x4ExtaddPairwiseI16x8S
* I32x4ExtAddPairWiseUI16x8 -> I32x4ExtaddPairwiseI16x8U
* I16x8Q15MulrSatS -> I16x8Q15mulrSatS
* I16x8NarrowSI32x4 -> I16x8NarrowI32x4S
* I16x8NarrowUI32x4 -> I16x8NarrowI32x4U
* I16x8ExtendLowSI8x16 -> I16x8ExtendLowI8x16S
* I16x8ExtendHighSI8x16 -> I16x8ExtendHighI8x16S
* I16x8ExtendLowUI8x16 -> I16x8ExtendLowI8x16U
* I16x8ExtendHighUI8x16 -> I16x8ExtendHighI8x16U
* I16x8ExtMulLowSI8x16 -> I16x8ExtmulLowI8x16S
* I16x8ExtMulHighSI8x16 -> I16x8ExtmulHighI8x16S
* I16x8ExtMulLowUI8x16 -> I16x8ExtmulLowI8x16U
* I16x8ExtMulHighUI8x16 -> I16x8ExtmulHighI8x16U
* I32x4ExtendLowSI16x8 -> I32x4ExtendLowI16x8S
* I32x4ExtendHighSI16x8 -> I32x4ExtendHighI16x8S
* I32x4ExtendLowUI16x8 -> I32x4ExtendLowI16x8U
* I32x4ExtendHighUI16x8 -> I32x4ExtendHighI16x8U
* I32x4DotSVecI16x8 -> I32x4DotI16x8S
* I32x4ExtMulLowSI16x8 -> I32x4ExtmulLowI16x8S
* I32x4ExtMulHighSI16x8 -> I32x4ExtmulHighI16x8S
* I32x4ExtMulLowUI16x8 -> I32x4ExtmulLowI16x8U
* I32x4ExtMulHighUI16x8 -> I32x4ExtmulHighI16x8U
* I64x2ExtendLowSI32x4 -> I64x2ExtendLowI32x4S
* I64x2ExtendHighSI32x4 -> I64x2ExtendHighI32x4S
* I64x2ExtendLowUI32x4 -> I64x2ExtendLowI32x4U
* I64x2ExtendHighUI32x4 -> I64x2ExtendHighI32x4U
* I64x2ExtMulLowSI32x4 -> I64x2ExtmulLowI32x4S
* I64x2ExtMulHighSI32x4 -> I64x2ExtmulHighI32x4S
* I64x2ExtMulLowUI32x4 -> I64x2ExtmulLowI32x4U
* I64x2ExtMulHighUI32x4 -> I64x2ExtmulHighI32x4U
* F32x4PMin -> F32x4Pmin
* F32x4PMax -> F32x4Pmax
* F64x2PMin -> F64x2Pmin
* F64x2PMax -> F64x2Pmax
* I32x4TruncSatSF32x4 -> I32x4TruncSatF32x4S
* I32x4TruncSatUF32x4 -> I32x4TruncSatF32x4U
* F32x4ConvertSI32x4 -> F32x4ConvertI32x4S
* F32x4ConvertUI32x4 -> F32x4ConvertI32x4U
* I32x4TruncSatZeroSF64x2 -> I32x4TruncSatF64x2SZero
* I32x4TruncSatZeroUF64x2 -> I32x4TruncSatF64x2UZero
* F64x2ConvertLowSI32x4 -> F64x2ConvertLowI32x4S
* F64x2ConvertLowUI32x4 -> F64x2ConvertLowI32x4U
|
|
|
|
|
|
|
|
|
| |
Renames the SIMD instructions
* LoadSplatVec8x16 -> Load8SplatVec128
* LoadSplatVec16x8 -> Load16SplatVec128
* LoadSplatVec32x4 -> Load32SplatVec128
* LoadSplatVec64x2 -> Load64SplatVec128
* Load32Zero -> Load32ZeroVec128
* Load64Zero -> Load64ZeroVec128
|
|
|
|
|
|
|
|
|
|
|
| |
Adds C/JS APIs for the SIMD instructions
* Load8LaneVec128 (was LoadLaneVec8x16)
* Load16LaneVec128 (was LoadLaneVec16x8)
* Load32LaneVec128 (was LoadLaneVec32x4)
* Load64LaneVec128 (was LoadLaneVec64x2)
* Store8LaneVec128 (was StoreLaneVec8x16)
* Store16LaneVec128 (was StoreLaneVec16x8)
* Store32LaneVec128 (was StoreLaneVec32x4)
* Store64LaneVec128 (was StoreLaneVec64x2)
|
|
|
|
| |
Also removes experimental SIMD instructions that were not included in the final
spec proposal.
|
|
|
|
|
| |
Works around #3682 With this, I can roundtrip
a large real-world testcase.
|
|
|
|
|
|
|
|
|
| |
We handled them as S63 instead of U32. That should be fine, as all U32 values fit
in S63. But it is not strictly correct. The signed encoding may use an additional byte
which is unnecessary, and there is an actual correctness issue where a U32 may
be interpreted as a large negative S63 (because it sign extends a final bit that
happens to be 1).
May help #3656 but that testcase still does not pass even with this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing a binary, we take the local indexes in the IR and turn
them into the format in the binary, which clumps them by type. When
writing the names section we should be aware of that ordering, but
we never were, as noticed in #3499
This fixes that by saving the mapping of locals when we are emitting
the name section, then using it when emitting the local names.
This also fixes the order of the types themselves as part of the
refactoring. We used to depend on the ordering of types to decide
which to emit first, but that isn't good for at least two reasons. First,
it hits #3648 - that order is not fully
defined for recursive types. Also, it's not good for code size - we've
ordered the locals in a way we think is best already (ReorderLocals pass).
This PR makes us pick an order of types based on that, as much as
possible, that is, when we see a type for the first time we append it to
a list whose order we use.
Test changes: Some are just because we use a different order than
before, as in atomics64. But some are actual fixes, e.g. in heap-types
where we now have (local $tv (ref null $vector)) which is indeed
right - v there is for vector, and likewise m for matrix etc. - we
just had wrong names before. Another example, we now have
(local $local_externref externref) whereas before the name was
funcref, and which was wrong... seems like the incorrectness was
more common on reference types and GC types, which is why this was
not noticed before.
Fixes #3499
Makes part of #3648 moot.
|
|
|
|
|
|
| |
We were missing a pop of catchIndexStack at a Delegate. It ends the scope,
so it should do that, like TryEnd does.
Found by emscripten-core/emscripten#13485 on -O2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was previously mistaken about `rethrow`'s argument rule and thought
it only counted `catch`'s depth. But it turns out it follows the same
rule `delegate`'s label: the immediate argument follows the same rule as
when computing branch labels, but it only can target `try` labels
(semantically it targets that `try`'s corresponding `catch`); otherwise
it will be a validation failure. Unlike `delegate`, `rethrow`'s label
denotes not where to rethrow, but which exception to rethrow. For
example,
```wasm
try $l0
catch ($l0)
try $l1
catch ($l1)
rethrow $l0 ;; rethrow the exception caught by 'catch ($l0)'
end
end
```
Refer to this comment for the more detailed informal semantics:
https://github.com/WebAssembly/exception-handling/issues/146#issuecomment-777714491
---
This also reverts some of `delegateTarget` -> `exceptionTarget` changes
done in #3562 in the validator. Label validation rules apply differently
for `delegate` and `rethrow` for try-catch. For example, this is valid:
```wasm
try $l0
try
delegate $l0
catch ($l0)
end
```
But this is NOT valid:
```wasm
try $l0
catch ($l0)
try
delegate $l0
end
```
So `try`'s label should be used within try-catch range (not catch-end
range) for `delegate`s.
But for the `rethrow` the rule is different. For example, this is valid:
```wasm
try $l0
catch ($l0)
rethrow $l0
end
```
But this is NOT valid:
```wasm
try $l0
rethrow $l0
catch ($l0)
end
```
So the `try`'s label should be used within catch-end range instead.
|