This Cl adds a type to {WasmTableObject}, and extends
{WasmTableObject::Set} and {WasmTableObject::Get} to support anyref
tables. I did it in one CL so that I can write tests.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I6c6d78f84715a7805f7bb881a63d3c1174f6a6ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511332
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60206}
In particular, remove {toUint8Array} method and make {toBuffer} return
a {Uint8Array} view to the buffer like before
https://crrev.com/c/1508352. Also, the returned view does not need to be
another copy of the bytes, it can really just be a view.
As a follow-up, this requires the test-only DeserializeWasmModule
runtime method to receive the wire bytes as Uint8Array, and also
requires the {IsWasmCompileAllowed} callback to handle
{ArrayBufferView} (like chromium's version already does).
R=ahaas@chromium.org
Change-Id: I87296cdbac14b74e7c8b38a372aa3df572ca6ad6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518172
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60195}
According to the wasm js-spec, the table index can be uint32. The
implementation in our implementation expected an int though. We did not
check for the int overflow.
I replaced the throwing of the exception in WasmTableObject::Get to use
the ErrorThrower instead of throwing the exception with Isolate::Throw
directly. The reason is that I see with other CL's that I have to throw
several errors, and I don't want to introduce a new message and
MessageId for every error. Moreover, the ErrorThrower is a standard way
in wasm to throw errors. It feels right to throw the error the same way
here.
R=mstarzinger@chromium.org
Bug: chromium:940296
Change-Id: Idb77c813506fe66a3192b66fe0e8e807b80580ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514496
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60181}
Reusing the same {Binary} object (with the same {ArrayBuffer}
underneath) speeds up the limits test with 1M functions by a factor of
11x in an optdebug build.
R=titzer@chromium.org
Change-Id: I36d032d652c66f5b7f5a80399588652d7e3946ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511475
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60127}
This CL cleans up a few things as noted by binji in
https://github.com/WebAssembly/spec/pull/979, plus a few more I found
along the way.
In particular:
1) Remove the unused and incorrect {bytesWithHeader} method.
2) Introduce kMaxVarInt32Size and kMaxVarInt64Size constants.
3) Remove redundant {ensure_space} calls (irrelevant for performance).
4) Use {toModule} method instead of duplicating code.
5) Merge two identical leb encoding implementations.
R=titzer@chromium.org
CC=binji@chromium.org
Change-Id: Idec74e2e46a71766107c182a4176c516d883adad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511273
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60124}
We have to create WasmExportedFunction objects for any WebAssembly
function which may escape a WebAssembly instance. Up until now we
created these WasmExportedFunction objects eagerly during instantiation
time: for any exported function, and any element in an exported table we
create such an object.
With the anyref proposal, the table.get instruction can allow any
function in a table to escape its instance. Therefore we would have to
create a WasmExportedFunction object for any function which is put into
a table.
With this CL we create WasmExportedFunctions for table entries lazily.
We initialize tables with placeholders consisting of the instance and
the function index. If we encounter a placeholder in table.get, we
create the WasmExportedFunction for the expected function to return it.
R=mstarzinger@chromium.orgCC=titzer@chromium.org
Bug: v8:7581
Change-Id: I4f32bd7433285d0b04a22c0fb70b736bac55b3f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505575
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60115}
Emitting bytes to the Uint8Array directly speeds up generation of
binaries enormously.
On the limits-any.js spec test (which creates huge modules), the
execution time of an optdebug build reduces from 286 seconds to 61
seconds.
R=titzer@chromium.org
CC=ahaas@chromium.org, ssauleau@igalia.com
Change-Id: I5b473b7dc7b0853e54d2406f3db3658bb2abed40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1508352
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60096}
This is a reland of 80f06d6fb3
Original change's description:
> [wasm] Lazy update instances on a shared Memory.Grow
>
> - Introduce a GROW_SHARED_MEMORY interrupt, and handler
> - Memory objects for isolates are updated on a stack check, add
> tracking for isolates that hit the stack check
> - When enough memory is not reserved ahead of time, fail to grow
> - Add tracking for externalized buffers in the MemoryTracker so
> that the MemoryTracker will know when backing_stores can be freed.
> - For shared buffer, do not always allocate a new buffer when
> growing an externalized buffer
>
>
> Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
> Bug: v8:8564
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60064}
Bug: v8:8564
Change-Id: Id0cf8e42a9d54ac702dba351e248a1b92713c98a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506357
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60071}
This reverts commit 80f06d6fb3.
Reason for revert: failing grow-memory tests
Original change's description:
> [wasm] Lazy update instances on a shared Memory.Grow
>
> - Introduce a GROW_SHARED_MEMORY interrupt, and handler
> - Memory objects for isolates are updated on a stack check, add
> tracking for isolates that hit the stack check
> - When enough memory is not reserved ahead of time, fail to grow
> - Add tracking for externalized buffers in the MemoryTracker so
> that the MemoryTracker will know when backing_stores can be freed.
> - For shared buffer, do not always allocate a new buffer when
> growing an externalized buffer
>
>
> Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
> Bug: v8:8564
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60064}
TBR=binji@chromium.org,titzer@chromium.org,gdeepti@chromium.org,ahaas@chromium.org
Change-Id: I2ed0b59bcbb285b701172b401d606963261d375c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506355
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60068}
- Introduce a GROW_SHARED_MEMORY interrupt, and handler
- Memory objects for isolates are updated on a stack check, add
tracking for isolates that hit the stack check
- When enough memory is not reserved ahead of time, fail to grow
- Add tracking for externalized buffers in the MemoryTracker so
that the MemoryTracker will know when backing_stores can be freed.
- For shared buffer, do not always allocate a new buffer when
growing an externalized buffer
Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
Bug: v8:8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60064}
The bulk memory operations should not bounds check ahead of time, but
instead should write as many bytes as possible until the first
out-of-bounds access.
Bug: v8:8890
Change-Id: Ia8179fe268fc65816c34a8f3461ed0a0d35600aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1497520
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60040}
Align the Table implementation limits with the JavaScript Embedding
limits defined in the specification (from MAX_UINT32 to 1e7).
Introduce a new helper (max_table_init_entries) that returns the
maximum number of Table entry at initialization. It takes into account
the maximum Table size, which can be passed by a flag.
Bug: v8:8633
Change-Id: Idfa19418e81f478f7886a30876e66c9b216e25ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496971
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60036}
Passive elements have a different binary format, where the contents are
instructions instead of function indexes:
0xd0 0x0b -> (ref.null)
0xd2 var:x 0x0b -> (ref.func x)
Bug: v8:8891
Change-Id: Ie7e8efe7b5acdf99622880dd97d28d3c13744dff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1497516
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60020}
Replaces assertErrorMessage by assertThrows. Previously
assertErrorMessage didn't assert the error message that was
provided.
Change-Id: I30410b43ff16db448776d9f3cae817b1c0966b3d
Reviewed-on: https://chromium-review.googlesource.com/c/1496973
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Cr-Commit-Position: refs/heads/master@{#59982}
Implement the ReturnCall functionality for the interpreter.
Note that some tests have had to be deferred to the implementation
of ReturnCall for TurboFan.
This a reland of https://chromium-review.googlesource.com/c/v8/v8/+/1467343
Bug: v8:7431
Change-Id: Iac9392a6a81995e30009dac74035e4d728ac3dbb
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1484905
Commit-Queue: Francis McCabe <fgm@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59925}
Implement the ReturnCall functionality for the interpreter.
Note that some tests have had to be deferred to the implementation
of ReturnCall for TurboFan.
Bug: v8:7431
Change-Id: I091528e72f9113ddf1929bd1a5650b490bc8cc0c
Reviewed-on: https://chromium-review.googlesource.com/c/1467343
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59803}
WasmI64AtomicWait checked alignment at 32 bit instead of 64 bit.
Bug=v8:8075
Change-Id: Ibd668ad8440e928d14a1fcae1577c4aae345151b
Reviewed-on: https://chromium-review.googlesource.com/c/1475918
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59713}
In the wasm streaming decoder error position test, do also check the
error messages generated. This revealed messages that were not quite
fitting and some that were formatted differently than the majority.
R=ahaas@chromium.org
Bug: v8:8814
Change-Id: If157f1083a104413bf14797ac56e756baac98c17
Reviewed-on: https://chromium-review.googlesource.com/c/1463780
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59604}
This CL contains the following changes:
(1) Allocate memory for WasmTables in the WasmInstance.
- We extend the WasmInstance by a FixedArray which stores
references to the WasmTables.
(2) Rename the name of the backing store of WasmTables from `functions`
to `elements`.
- The name `functions` just does not fit anyref tables.
(3) Generate code with TurboFan for table.get and table.set.
(4) Extend wasm-module-builder.js to be able to generate modules with
multiple tables.
(5) Add mjsunit tests to test table.get and table.set.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I44af4838ee7a37b394841a2f673ecae5734a4d1c
Reviewed-on: https://chromium-review.googlesource.com/c/1463519
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59529}
This makes the existing error message tests also test the error
produced by asynchronous compilation and instantiation.
It also slightly tweaks the error message to contain the name of the
API function invoked instead of "WebAssembly Instantiation".
R=titzer@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: If4ab963cee8267d43b289169d21b31637c471d6d
Reviewed-on: https://chromium-review.googlesource.com/c/1456085
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59442}
We often use raw assertPromiseResult with {success ==
assertUnreachable} for that. Having a separate helper increases
readability and allows us to generate consistent (and better) error
messages.
R=titzer@chromium.org
Bug: chromium:926311
Change-Id: I507941eacaafe6c576098d7829a76b27384a4fb6
Reviewed-on: https://chromium-review.googlesource.com/c/1456039
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59417}
Remove the call to [[HasProperty]] for the shared property when threads
feature is enabled.
Bug: v8:8782
Change-Id: I492ed3726ea846a1a52dc3a0e0a183d9ee506e96
Reviewed-on: https://chromium-review.googlesource.com/c/1451826
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Cr-Commit-Position: refs/heads/master@{#59352}
This is a reland of a9e93572d4
Original change's description:
> [test] Check for illegal uses of mjsunit methods
>
> The assertThrows and assertDoesNotThrow methods expect either a
> function to execute, or a string to eval. In several tests however we
> accidentally passed the *result* of the statement to be tested instead
> of the code.
> This CL adds check to catch such error early, and removes wrong uses.
> In most places, we do not need to use assertDoesNotThrow anyway,
> because exceptions are handled as test failures.
>
> Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
> MjsUnitAssertionErrors correctly.
>
> R=mathias@chromium.org
>
> Bug: v8:8562
> Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
> Reviewed-on: https://chromium-review.googlesource.com/c/1439238
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59277}
Bug: v8:8562
Change-Id: I3b26935f7b35302d499266155273ea271bf8151d
Reviewed-on: https://chromium-review.googlesource.com/c/1449792
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59328}
This CL revises some of our error messages, and removes unneeded parts
(like "AsyncCompilation: " or "(null): "). It also extends existing
tests to check for the precise error message more thoroughly to detect
changes or nondeterminism earlier.
R=titzer@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: I1ccfb307d4a61291f4582330152a53fbadd0848f
Reviewed-on: https://chromium-review.googlesource.com/c/1445897
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59296}
This reverts commit a9e93572d4.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/23956
Happened already 2 builds earlier, but the output is corrupted due to
an outage.
Original change's description:
> [test] Check for illegal uses of mjsunit methods
>
> The assertThrows and assertDoesNotThrow methods expect either a
> function to execute, or a string to eval. In several tests however we
> accidentally passed the *result* of the statement to be tested instead
> of the code.
> This CL adds check to catch such error early, and removes wrong uses.
> In most places, we do not need to use assertDoesNotThrow anyway,
> because exceptions are handled as test failures.
>
> Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
> MjsUnitAssertionErrors correctly.
>
> R=mathias@chromium.org
>
> Bug: v8:8562
> Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
> Reviewed-on: https://chromium-review.googlesource.com/c/1439238
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59277}
TBR=ahaas@chromium.org,clemensh@chromium.org,mathias@chromium.org
Change-Id: Iec06c95dd3223f27297e5c6e02835d26b5e753e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8562
Reviewed-on: https://chromium-review.googlesource.com/c/1449634
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59284}
The assertThrows and assertDoesNotThrow methods expect either a
function to execute, or a string to eval. In several tests however we
accidentally passed the *result* of the statement to be tested instead
of the code.
This CL adds check to catch such error early, and removes wrong uses.
In most places, we do not need to use assertDoesNotThrow anyway,
because exceptions are handled as test failures.
Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
MjsUnitAssertionErrors correctly.
R=mathias@chromium.org
Bug: v8:8562
Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
Reviewed-on: https://chromium-review.googlesource.com/c/1439238
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59277}
This CL revises some of our error messages to be more precise or more
aesthetically appealing.
R=titzer@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: I38eaee09fd37f9b67fdb08bc7b0df64a6eaf96f9
Reviewed-on: https://chromium-review.googlesource.com/c/1445980
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59249}
We noticed that almost every call site were loading both files,
the split isn't necessary anymore.
In some message tests, removed the absolute line number to allow future
changes.
Bug: v8:8726
Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545
Reviewed-on: https://chromium-review.googlesource.com/c/1446452
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59220}
Changes made to the Wasm module builder:
- Create emit_u64v for emitting a LEB128 that conceptually represent
an 64-bits integer.
- Differentiate toBuffer and toUint8Array for returning respectively
ArrayBuffer and a Uint8Array.
- Moved wasmF32Const and wasmF64Const functions because we can take
advantage of the existing cached conversion buffers. Also, declaring
them in the constants file will collide with the module-builder since
they are loaded in the same scope.
- The byte_view buffer (used by some conversions to bytes) switched from
Int8Array to Uint8Array.
Changes made to the Wasm contants:
- Add a new kSharedHasMaximumFlag flag for shared memory with a maximum
value.
Bug: v8:8726
Change-Id: If16c59896cfa1d42008da413e2e144b73a0fa5ce
Reviewed-on: https://chromium-review.googlesource.com/c/1443062
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Cr-Commit-Position: refs/heads/master@{#59213}
Anyref parameters can exist across GC runs. Therefore the GC has to
know where anyref parameters are on the stack so that it can mark them
in its marking phase, and update them in the compaction phase.
Already in a previous CL we grouped all anyref parameters so that they
can be found more easily in a stack frame, see
https://crrev.com/c/1371827. In this CL we implement the stack scanning
itself.
Note that anyref parameters are not scanned while iterating over the
caller's frame (to which they actually belong), but while iterating
over the callee's frame. The reason is that with tail-calls, only the
callee knows how many tagged stack parameters (aka anyref parameters)
there are.
R=mstarzinger@chromium.orgalso-by=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
Reviewed-on: https://chromium-review.googlesource.com/c/1424955
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59099}
For the reference types anyref, anyfunc, and nullref, there exist
sub-typing rules. The spec says
A reference type reftype1 matches a reference type reftype2 if and only
if:
* Either both reftype1 and reftype2 are the same.
* Or reftype1 is nullref.
* Or reftype2 is anyref.
This CL introduces the type nullref for ref-null, and implements the
sub-typing rules in the function-body-decoder.
Note that because of the sub-typing check validation performance may
regresses. In that case we can optimize the sub-typing check.
R=titzer@chromium.org, clemensh@chromium.org
Bug: v8:7581
Change-Id: I55bab72a109f3374da3770d141b0fc8067aad8b2
Reviewed-on: https://chromium-review.googlesource.com/c/1430061
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59043}
The implementation already exists, but the test doesn't.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I42e1b0a1c930ec4cc1f1701d5613828acab4fc30
Reviewed-on: https://chromium-review.googlesource.com/c/1426123
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59038}
The table.init bytecode copies a range of elements from an element
segment into a table, trapping if the segment is not passive, is
dropped, or would cause out-of-bounds accesses.
R=mstarzinger@chromium.orgCC=binji@chromium.org
BUG=v8:7747
Change-Id: Ib27af9cca45a464fd1f876ddd092e99941481896
Reviewed-on: https://chromium-review.googlesource.com/c/1430063
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59037}
Fix WebAssembly's memory/grow js-api. The argument is a unsigned long,
this change refactors most of arithmetic and bounds checks type from int64 to
uint32_t, according to the spec.
Bug: v8:8319
Change-Id: I662c704d1d50288ad68be70c72a3db7052a80014
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1351028
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59008}
Fix WebAssembly's table/get-set js-api. The argument is a unsigned long,
this change refactors most of arithmetic and bounds checks type from
int64 to uint32_t, according to the spec.
Bug: v8:8319
Change-Id: I088f631c6805b0e5ba29089b08ea15e78fe5852d
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1414914
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Cr-Commit-Position: refs/heads/master@{#58941}
Fix WebAssembly's table/grow js-api. The argument is a unsigned long,
this change refactors most of arithmetic and bounds checks type from
int64 to uint32_t, according to the spec.
Bug: v8:8319
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: Ia29121c930d7fb930668e54a5a769dae25234f2c
Reviewed-on: https://chromium-review.googlesource.com/c/1351006
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58936}
This CL fixes the zero-count and overlapping cases for the table.copy
bytecode.
R=mstarzinger@chromium.orgCC=binji@chromium.org
BUG=v8:7747
Change-Id: I6211e4c899621069ebf8bc088b3ab4e80c7bbd0a
Reviewed-on: https://chromium-review.googlesource.com/c/1417172
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58887}
Implementation of anyfunc parameters. Different to anyref parameters we
have to do a validation in the js-to-wasm wrapper: Only exported wasm
functions are allowed. I implemented this check in a runtime function.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I6145782fb8578124ddc21b50133c82235d666f19
Reviewed-on: https://chromium-review.googlesource.com/c/1417470
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58885}
Fix WebAssembly's global/value-get-set. The argument must not be
undefined.
mjsunit tests were updated.
Bug: v8:8319
Change-Id: Id3d3c9b18cbc8854e589481dfc7c52f35cfb7bf7
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1411886
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Cr-Commit-Position: refs/heads/master@{#58863}
The table.copy bytecode copies a range of table entries in a similar
way to memcopy. This CL implements the behavior in a runtime call
that calls into the wasm engine.
R=mstarzinger@chromium.org,binji@chromium.org
BUG=v8:7747
Change-Id: I420451202b1b78ea92cbd10387a644ed57e111c8
Reviewed-on: https://chromium-review.googlesource.com/c/1414919
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58858}
This switches the experimental exception handling implementation to the
new proposal where 'catch' blocks behave in a catch-all fashion and a
new 'br_on_exn' operation is used to check for a certain exception type
and extract the exception values on a match.
R=clemensh@chromium.org
TEST=unittests/FunctionBodyDecoderTest,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: Ib12ba28b3aa2a7d831312a83abcb00bf56d0adc3
Reviewed-on: https://chromium-review.googlesource.com/c/1409431
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58832}
With this CL we support importing mutable anyref globals. The CL
contains the following changes:
* We store a reference to the buffer of the imported global in
`WasmInstance::imported_mutable_globals_buffer`. This FixedArray is
already used to keep the ArrayBuffers of value-typed imported
mutable globals alive but was not accessed otherwise.
* We store the offset in the buffer of the imported global in
`WasmInstance::imported_mutable_globals`. This `Address`-array is
used for value-typed imported mutalbe globals to store direct
pointers into the backing store of the ArrayBuffer of the imported
global.
* In wasm-compiler.cc we generate code to load these fields and then
load or store globals.
* in module-compiler.cc I removed the counter variable
`next_imported_mutable_global_index`. The variable was only used for
a DCHECK. I replaced the DCHECK with a slightly weaker DCHECK now.
* Tests.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I11f0f4d8637c98eded5fb2eec44bc8ead8ed5c7b
Reviewed-on: https://chromium-review.googlesource.com/c/1409169
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58822}
The table.drop bytecode "drops" the backing storage for an element
initializer. In the V8 implementation, this is a nop, other than
updating a per-instance boolean array so that two drops of the same
segment or a drop of an active segment will trap.
This is implemented with inline code in TurboFan in order to be symmetric
to memory.drop, but could as easily be a runtime call to be supported in
Liftoff.
R=mstarzinger@chromium.org
CC=binji@chromium.org
BUG=v8:7747
Change-Id: Ic017398eaa764dd3a9ff19523453ff7142c9abf6
Reviewed-on: https://chromium-review.googlesource.com/c/1408996
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58817}
This CL adds two new runtime calls for table operations:
- Runtime_WasmTableInit
- Runtime_WasmTableCopy
These runtime calls (will) implement the semantics for the corresponding
bytecodes from the bulk memory proposal. The actual implementation
of these runtime calls will be done in further CLs.
The third table operation, table.drop, will be implemented with inline
code, similar to memory.drop. This is also be done in a further CL.
R=mstarzinger@chromium.org
CC=binji@chromium.org
BUG=v8:7747
Change-Id: I498aa054329baf9f72ae55d245b12c3ccd4157b7
Reviewed-on: https://chromium-review.googlesource.com/c/1408994
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58786}
It removes the assertion that caused the bug report by introducing a new
trampoline (WasmBigIntToI64) for the conversion code stub between a Bigint
object and a Wasm i64 BigIntToI64).
The tests were updated to cover calling the stub from a Wasm callsite.
Bug: v8:8625
Change-Id: I55891001cfa72f6f2849792293b43bbb54147f1a
Reviewed-on: https://chromium-review.googlesource.com/c/1405028
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58767}
This CL adds support for anyref in WebAssembly.Global objects. Note
that the specification is not complete yet in this area.
I did the following changes:
- I renamed the `array_buffer` field of WasmGlobalObject to
`untagged_buffer`
- I added an additional field of type FixedArray, `tagged_buffer`.
- In the constructor of WasmGlobalObject I allocate either the former
or the latter, but not both.
- In the WebAssembly.Global constructor I added special handling for
the case where no initial value is provided. In that case I set the
inital value to `null` and not to `undefined`.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I7e4855d7e6c04a9bcdc7ebd450caca5819d060e2
Reviewed-on: https://chromium-review.googlesource.com/c/1398226
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58625}
Fix WebAssembly's global/constructor js-api. Globals with a value
of i64 is now valid even if Wasm BigInt feature isn't activated.
Bug: v8:8319
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: Ia41ad69efa5253064ecdb8f59b149393cd672b68
Reviewed-on: https://chromium-review.googlesource.com/c/1382747
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58603}
With this CL it is possible to import any JavaScript object as an anyref
global. The exception is WasmGlobalObject, which cannot hold anyref
globals yet.
R=clemensh@chromium.org
Bug: v8:7581
Change-Id: I5b0fc686a4ec5c579d1d635b53be5ccdf0a78f27
Reviewed-on: https://chromium-review.googlesource.com/c/1382452
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58557}
We currently trigger a GC when creating a module while the remaining
uncommitted code space is below 32MB. For bigger modules, this is not
enough. Instead, make this limit relative: Trigger GC if we fall below
50% of the available code space, and re-adjust this limit after each GC
to avoid repeated GCs that do not free anything.
R=ahaas@chromium.org
Bug: v8:8624
Change-Id: I7abfad3b57663d528a26d29232ad6bc2dc63cef4
Reviewed-on: https://chromium-review.googlesource.com/c/1391753
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58527}
Identify validation fails to read the index of prefixed opcodes, and not
continue to decode the next bytes.
Change-Id: I2c737af55615ba69ba0c5f5adf18a06c6cdb951a
Bug: chromium:905815
Reviewed-on: https://chromium-review.googlesource.com/c/1390927
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58485}
The source register of {movsx_b} must be a byte register.
Drive-by: Add missing sign extension opcodes to wasm-constants.js.
R=herhut@chromium.org
Bug: chromium:916869
Change-Id: I571c1ea2a0e197afefc810f306eed238250cd5e0
Reviewed-on: https://chromium-review.googlesource.com/c/1386110
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58394}
This CL implements the global.get and global.set instruction for anyref
globals. This includes:
* Properly decode anyref globals.
* Add a FixedArray to WasmInstanceObject to store anyref globals.
* Initialize the FixedArray.
* Generate code for global.get and global set.
This CL does not allow to import globals yet.
R=clemensh@chromium.org
Bug: v8:7581
Change-Id: I62617409271d9b6f2253a191681189865aa1f459
Reviewed-on: https://chromium-review.googlesource.com/c/1380112
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58318}
ProtectedLoad/ProtectedStore opcodes are used in WebAssembly to represent memory
accesses. Since they are not part of the allowed opcodes in OwnedByAddressingOperand
it is not possible to take advantage of addressing modes to encode common patterns
for the pointer input value.
R=jarin@chromium.org
Bug: v8:8508
Change-Id: Ic62bf13fed7b1d86afb112d9aa59cd7073a28e72
Reviewed-on: https://chromium-review.googlesource.com/c/1354458
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58237}
`memory.init` copies bytes from a passive data segment to linear memory.
`memory.drop` is an instruction that informs the wasm VM that the instance no
longer needs access to the passive data segment.
Information about the passive data segments, including their contents, length,
and whether they are dropped, is stored in the `WasmInstanceObject` as primitive
arrays.
Bug: v8:7747
Change-Id: I1515c8868c9be227743456a539126c15280b5365
Reviewed-on: https://chromium-review.googlesource.com/c/1370691
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58196}
These are some tests I thought were missing. I wrote another test which
crashes because of missing safepoint maps. I will add it in a separate
CL which includes also the implementation.
R=herhut@chromium.org
Bug: v8:7581
Change-Id: Ibcc3b9ddab0f95580eb31fe78c84a26186a74db5
Reviewed-on: https://chromium-review.googlesource.com/c/1370039
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58159}
Uses the JavaScript BigInt Object to represent Wasm's 64bits integers.
Attention, 32 bits architectures are not supported yet.
Bug: v8:7741
Change-Id: I28b718fa567bca5103b2f38a879049cd20a46f12
Reviewed-on: https://chromium-review.googlesource.com/c/1355144
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58152}
Fix and re-enable tests for WebAssembly's memory/constructor and
table/constructor js-api.
It introduces the '[EnforceRange] unsigned long' algorithm used
to validate initial and maximum properties.
The initial property is now required, by the switch to the Web IDL
specification. Most of the input validations errors are now considered
TypeError instead of RangeError.
The WasmTableObject and WasmMemoryObject APIs use more consistently uint32_t
to ensure integer range and remove the need for bounds checks.
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: v8:8319
Change-Id: Iedd3ee6484ef688a5e96f93006eb6ca66d805a48
Reviewed-on: https://chromium-review.googlesource.com/c/1354043
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58138}
This implementation currently only supports the optimized tier.
Bug: v8:7747
Change-Id: Ia1af29b11a5d3e8a48b122f6cf3240c9f5948bfb
Reviewed-on: https://chromium-review.googlesource.com/c/1364710
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58137}
Just pass a pointer to the current stack. This makes it easier to reuse
the {DoReturn} method for breaks to the outermost block.
R=titzer@chromium.org
Bug: v8:8423
Change-Id: Ide8533b154daa227e044820bb9c181f836ba654a
Reviewed-on: https://chromium-review.googlesource.com/c/1370028
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58132}
This is a reland of 9c2c8f15f8
Original change's description:
> [wasm] Support encoding s128 simd types in exceptions.
>
> This adds support for having simd type values (i.e. s128) stored in an
> exception. It is the natural combination of the simd propsal and the
> exception handling proposal.
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-simd
> BUG=v8:8390
>
> Change-Id: I01079f82a6ba4d9152de4dae63e3db1584ca7cd8
> Reviewed-on: https://chromium-review.googlesource.com/c/1363141
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58098}
Bug: v8:8390
Change-Id: I333c50cd766055f74b023df626d0fd90fdef3bac
Reviewed-on: https://chromium-review.googlesource.com/c/1370024
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58122}
This reverts commit 9c2c8f15f8.
Reason for revert: New test crashes: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux/28948
Original change's description:
> [wasm] Support encoding s128 simd types in exceptions.
>
> This adds support for having simd type values (i.e. s128) stored in an
> exception. It is the natural combination of the simd propsal and the
> exception handling proposal.
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-simd
> BUG=v8:8390
>
> Change-Id: I01079f82a6ba4d9152de4dae63e3db1584ca7cd8
> Reviewed-on: https://chromium-review.googlesource.com/c/1363141
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58098}
TBR=mstarzinger@chromium.org,gdeepti@chromium.org,clemensh@chromium.org
Change-Id: Iedcfba36af925249131a2b0e9aebd92321ae72f5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8390
Reviewed-on: https://chromium-review.googlesource.com/c/1367808
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58102}
This adds support for having simd type values (i.e. s128) stored in an
exception. It is the natural combination of the simd propsal and the
exception handling proposal.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-simd
BUG=v8:8390
Change-Id: I01079f82a6ba4d9152de4dae63e3db1584ca7cd8
Reviewed-on: https://chromium-review.googlesource.com/c/1363141
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58098}
Make sure WebAssembly's js-api exposes the correct attributes: writable,
enumerable and configurable.
Bug: v8:8319
Change-Id: I427533159d7975a42c0c5cb1babdc8a61f8198b5
Reviewed-on: https://chromium-review.googlesource.com/c/1351002
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58053}
The placement of the exceptipon section is by now restricted to be in
between the Global and the Import section. This changes our validation
to check this stricter requirement now.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: Ib3ea625fd4df93bffda47ced09e6969159f7ac70
Reviewed-on: https://chromium-review.googlesource.com/c/1356504
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57962}
This is a reland of 9436e8a817
This CL simplifies the wasm/futex.js test so that it doesn't push the
limits of d8.
Original change's description:
> [wasm] Add I64AtomicWait implementation
>
> Bug=v8:8075
> R=adamk@chromium.org,binji@chromium.org
>
> Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/1342948
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57917}
Change-Id: Ifd26f1ecdb9fe24a1896162bb4d4285f9188a9ba
Reviewed-on: https://chromium-review.googlesource.com/c/1351304
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57953}
Bug=v8:8075
R=adamk@chromium.org,binji@chromium.org
Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
Reviewed-on: https://chromium-review.googlesource.com/c/1342948
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57917}
This constant is unused, and should never be used, since name sections
are encoded as an unknown section with the special name "name".
R=ahaas@chromium.org
Change-Id: I2fa1a21506dbe30033aecb3c1bf9ad84b6b872bc
Reviewed-on: https://chromium-review.googlesource.com/c/1352305
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57905}
The {setTableLength} method is redundant and has a single user. Remove
it, use {setTableBounds} instead.
Drive-by: Add default to the table max, to document that this can
actually be {undefined}, in which case the table has no maximum.
R=binji@chromium.org
Bug: v8:8238
Change-Id: I0d7a2f4d49d083f7adadbb4b6cd4933bcb1dc174
Reviewed-on: https://chromium-review.googlesource.com/c/1350126
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57860}
This CL adds new Wasm import call kinds that correspond to various
math functions that can be imported from JavaScript, such as trigonometry.
Instead of calling a special import wrapper that converts arguments
to tagged values by boxing, we can now generate calls to little WASM
stubs that contain a single WASM bytecode each.
R=mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1349279
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57835}
This CL implements an assembly order optimization that moves blocks
that end a loop with an unconditional backedge to the beginning of
the loop, saving a branch.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867
Reviewed-on: https://chromium-review.googlesource.com/c/1335944
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57572}
See the WebAssembly bulk memory proposal here:
https://github.com/WebAssembly/bulk-memory-operations
This initial CL adds a wasm experimental flag:
`--experimental-wasm-bulk-memory`, and also parsing of passive segments.
A passive segment is one that is not copied into the table/memory on
instantiation, but instead later via the `{table,memory}.init`
instructions.
The binary format of passive data segments is unlikely to change, but
the format for passive element segments may change (see
https://github.com/WebAssembly/bulk-memory-operations/pull/39).
Bug: v8:7747
Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858
Reviewed-on: https://chromium-review.googlesource.com/c/1330015
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57451}
I just ran into this when creating a test case. The huge spread caused
a RangeError (stack overflow). It's not causing problems for the tests
we currently have, but let's fix it anyway.
R=ahaas@chromium.org
Change-Id: Ib67f059f2981ccc6239ba4ae05611e20eb3aa191
Reviewed-on: https://chromium-review.googlesource.com/c/1329177
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57429}
The flag is on by default, so we don't need to specify it. More
importantly, the tests are expected to work for any value of that flag.
So don't force the flag but use whatever the test variant chooses.
Note that in streaming-compile.js, the flag was accidentally specified
as '-async-compilation'. I also removed that one.
R=ahaas@chromium.org
Change-Id: Ifad31160d266dda38cdd9dd1d73dad69bd2c2f2c
Reviewed-on: https://chromium-review.googlesource.com/c/1325961
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57406}
These tests are also used for streaming. This CL changes the test to
actually output the exception that unexpectedly happened.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: Ia9c91a7d3d9452f9c0180329a5434f049b56c3c8
Reviewed-on: https://chromium-review.googlesource.com/c/1319755
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57284}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
This adds support for having reference type values (i.e. anyref) stored
in an exception. It is the natural combination of the reference type
proposal and the exception handling proposal.
Note that this also introduces support for having write barriers in
generated WasmCode, as this is the first time we are storing references
within generated code. Such write barriers will be needed for other uses
of reference types (e.g. mutable global) regardless.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref
BUG=v8:8341
Change-Id: I1211d4a850954622cb873eede0b4024fecc3dd8b
Reviewed-on: https://chromium-review.googlesource.com/c/1296484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56995}
