Anyfunc globals are very similar to anyref globals. This CL is mostly
about extending the conditions which guard the anyref globals code.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: Ia92ac4560102cc3ed0060342f92758db28f415ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526004
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60281}
The existing has property handling did not account for the fact an IC can have LOAD_IGNORE_OUT_OF_BOUNDS while some of the maps in the IC do not allow out of bounds loads.
bug: chromium:942068
Change-Id: I935402d9d72e9c0228510ef69154ea130d1c71f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1525876
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60269}
This CL allows for either of 'minimum' or 'initial' for MemoryDescriptor
and TableDescriptor. It also adds a flag for the reflection features.
R=binji@chromium.org,adamk@chromium.org
Bug=v8:7742
Change-Id: Icfd4825f63e1eb784a39d10f740d55e81489eba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1485243
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60256}
This CL only provides the implementation of memory.{init,copy,fill} and
data.drop.
Bug: v8:8965
Change-Id: I439f2520bfee8f147e4b0d1d31f954aaad2e14ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510575
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60253}
R=binji@chromium.org,adamk@chromium.org
Bug=v8:7742
Change-Id: I5b9a614dd0c8b028d756cbd401c803de4cb9437f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1513159
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@{#60252}
This CL also changes the constructor for WasmTableObject so that the
maximum_length is set to undefined instead of a default value if there's
no maximum provided.
R=binji@chromium.org,adamk@chromium.org
Bug=v8:7742
Change-Id: I6310224e9997464bf69c198e2694a6cd76e01e8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1513156
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60250}
Compilation only stores whether an error has been found, but not the
exact error or it's location. This is generated by running a validation
pass once all wire bytes have been received.
This unifies error messages by removing one more location where we
generate compilation error messages, and makes it deterministic because
a) we always report the error in the first failing function, and
b) if names are present, the error message will always contain the
function name.
R=titzer@chromium.org
Bug: chromium:926311, v8:8814
Change-Id: I79551b8bb73dcee503484de343a3ada60a6add4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1521112
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60242}
Add a CheckSmi call to the value of the position argument to
String.prototype.startsWith(search, [position]).
Bug: v8:8400, chromium:939746
Change-Id: I7462bebe0d3fde605a4c27a34c0d9bb3f0cc1c20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514198
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60216}
This CL just adds a parameter to addElementSegment and adjusts all
existing tests.
Note that addElementSegment contains some convenience code to construct
one initial table if it does not exist yet. I did not extend that code
to multiple tables. If you want to use multiple tables, you have to
create them first before calling addElementSegment.
R=clemensh@chromium.org
Bug: v8:7581
Change-Id: Ie131fd5dc19856703ab5cfb2fa8f7d576f70a18b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520709
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60211}
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}
The regexp interpreter holds several unhandlified references to heap
objects, and is thus within a DisallowHeapAllocation scope. But there
are two situations in which we can and do allocate safely:
1. When creating & throwing a stack overflow exception. The interpreter
aborts afterwards, and thus possible-moved objects are never used.
2. When handling interrupts. We manually relocate unhandlified references
after interrupts have run.
This CL explicitly allows allocations on stack overflows.
Isolate::StackOverflow allocates heap objects.
Bug: chromium:940722, v8:8724
Change-Id: I74ef6f0dd7a30bd55f49a7bc0f2f6ac82adbeda8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518174
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60191}
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}
When given a sticky regexp s.t. lastIndex > subject.length, the
following should happen:
1. exec returns null (= no match)
2. lastIndex is reset to 0.
This is usually done by the RegExp.p.exec builtin; but in some cases
we take different paths and try to re-implement the parts of exec that
we need.
One of these cases was in %StringReplaceNonGlobalRegExpWithFunction.
Here, we set lastIndex to 0 but then incorrectly called into
RegExpImpl::Exec. REI::Exec started matching with lastIndex == 0,
which is just plain wrong. With this CL we now correctly omit the
REI::Exec call and return null.
Bug: chromium:937681, v8:5361
Change-Id: I6bb1114a6b92ed3c6e63ec7f6ec2df4b95a19b4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514679
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60169}
It wasn't always guaranteed that they were serialized before taking the
dependency.
Bug: chromium:940361
Change-Id: Id5e5e14532809e7496546c2011176e33848506ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514495
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60156}
If the branch associated with the condition is kDead, the current
node will be killed anyway, so let us just survive the lowering.
Bug: chromium:935092
Change-Id: If7b39e3b5452d6c9bc5199080eb38725e6c4eab5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1488769
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60143}
Call to ReduceKeyedLoadFromHeapConstant got lost in rebasing,
as did the kHas check in ReduceElementAccessOnString. Added
some tests to ensure both cases are covered.
Change-Id: I8d6992c33315436b6228471b9bc57e3b267ad09f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1508837
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60132}
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}
RotateRight32 needs a "number of bits" operand in the range 0..31.
Thankfully that's how x86 shift instructions behave anyway, and
how the bitwise shift operators in JavaScript are spec'ed, so this
fix is unobservable in non-UBSan builds.
RemoveArrayHolesGeneric can be used for length values anywhere in
the uint32_t range, so it must not implicitly cast those to int.
That actually caused an observable bug where a proxy's traps would
not get called at all, but only for huge "length" properties, where
the entire operation would also be painfully slow.
Bug: chromium:935133, chromium:937652
Change-Id: I13f74ca27eae6b2b089d58217842b699b2574509
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510272
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60112}
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}
Fixing a few float and int overflows.
Drive-by fix: with --experimental-wasm-bigint, Number values
may not be used to initialize i64-typed globals. The existing
code for doing that relied on UB; since it's a spec violation
the fix is to throw instead.
No regression test for 933103 because it will OOM anyway.
No regression test for 932896 because it would be extremely slow.
Bug: chromium:927894, chromium:927996, chromium:930086, chromium:932679, chromium:932896, chromium:933103, chromium:933134
Change-Id: Iae1c1ff1038af4512a52d3e56b8c4b75f2233314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495911
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60075}
ReduceJSHasProperty was always passing STANDARD_LOAD instead of using the load mode from
the feedback verctor. This was causing deopt loops when checking for out-of-bounds
indices.
chromium: 937734
Change-Id: I6de29f2c6a80bcc171cf027d47a2d1af1414b76c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1501975
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60073}
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}
Causes flakyness in TSAN runs when flag is written by EnforceFlagImplications
and read by ConcurrentMarking.
BUG=v8:8924
Change-Id: I2b0bf0fbb678e03492d7ed13e48657de9316b700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505796
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60062}
This piggy-backs off similar support for lite mode, which silently skips
tests that require optimization in lite (and now jitless) modes.
Bug: v8:7777,v8:8778, v8:8885
Change-Id: I666d92685ca71682224028743f02d0cce3723135
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503758
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60057}
Unicode v12 was released today:
https://unicode.org/versions/Unicode12.0.0/
This patch updates the following sequence property escapes per
Unicode 12:
- Emoji_Flag_Sequence (no changes)
- Emoji_Keycap_Sequence (no changes)
- Emoji_Tag_Sequence (no changes)
- Emoji_ZWJ_Sequence
Note that Emoji_Modifier_Sequence is still using Unicode 11 data. This
will be fixed automatically once a version of ICU with Unicode 12 support
rolls into V8, at which point I'll update the relevant tests.
Bug: v8:7467
Change-Id: Iba575a471382ba7b029da06c2868c368ff43c649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503764
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60052}
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}
In the recent port of reduce() and reduceRight(), a check for a length
change during the loop (standard for iterating builtins) was omitted.
We did get array bounds check protection, however it didn't expose
the issue in our tests because the bounds check is against the
backing store length, not against the length in the referring JSArray.
Also added a test for reduceRight().
R=jgruber@chromium.org
Bug: chromium:937676
Change-Id: I76e22e0d71965bff84a0822b1df5dc818a00b50e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503732
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60033}
