In Chromium tree, ICU is rolled to 63.1. And, auto-roller will soon
try to roll ICU in v8 to 63.1. Due to a nodejs trybot issue,
autoroll needs a manual intervention. In the meantime, this CL
will get rid of other blocking issues for ICU update.
Prepare for the ICU roll by revising test/intl as following:
* Line breaking loose mode is now supported in the
Chromium's copy of ICU. Adjust the test expectation.
* ICU's uloc_* can handle overlong locale ids. Drop tests
that are not valid any more.
Once ICU is rolled, a couple of TSAN-suppressed tests can
be unsuppressed, but that has to be done in a separate CL.
Bug: chromium:893196,v8:8272, v8:8110
Test: intl/*, test262/test402/*
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I17f11457b61376b1e8d41bbbc951fa6cd3355a54
Reviewed-on: https://chromium-review.googlesource.com/c/1289369
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57105}
Fix the to be-landed-soon test262 test failure in
test262/intl402/Collator/prototype/resolvedOptions/order
The spec changed from "any order" to "table " order
in https://github.com/tc39/ecma402/pull/279
Bug: v8:8378
Change-Id: I76cfb27ab4219911e6ab2de97f0f34318d5430a3
Reviewed-on: https://chromium-review.googlesource.com/c/1302801
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57104}
Change the order of the output and add spec text.
To fix the to-be-landed-soon test262 test failure in
test262/intl402/Segmenter/prototype/resolvedOptions/order
The spec change from "any order" to "table " order
in https://github.com/tc39/ecma402/pull/279
Bug: v8:8376
Change-Id: Ife19aec4386a022168514053830ebe03f983f4a9
Reviewed-on: https://chromium-review.googlesource.com/c/1301646
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57100}
This will give us some clusterfuzz coverage.
Bug: v8:6891
Change-Id: I167774aeb0110bde8d5ed1047b2875b14317903b
Reviewed-on: https://chromium-review.googlesource.com/c/1301643
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57099}
This introduces Word64 support for the CheckBounds operator, which now
lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
representation selection. The right hand side of CheckBounds can now
be any positive safe integer on 64-bit architectures, whereas it remains
Unsigned31 for 32-bit architectures. We only use the extended Word64
support when the right hand side is outside the Unsigned31 range, so
for everything except DataViews this means that the performance should
remain the same. The typing rule for the CheckBounds operator was
updated to reflect this new behavior.
The CheckBounds with a right hand side outside the Unsigned31 range will
pass a new Signed64 feedback kind, which is handled with newly introduced
CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
selection.
The JSCallReducer lowering for DataView getType()/setType() methods was
updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
but instead just use the raw uintptr_t values and operate on any value
(for 64-bit architectures these fields can hold any positive safe
integer, for 32-bit architectures it's limited to Unsigned31 range as
before). This means that V8 can now handle huge DataViews fully, without
falling off a performance cliff.
This refactoring even gave us some performance improvements, on a simple
micro-benchmark just exercising different DataView accesses we go from
testDataViewGetUint8: 796 ms.
testDataViewGetUint16: 997 ms.
testDataViewGetInt32: 994 ms.
testDataViewGetFloat64: 997 ms.
to
testDataViewGetUint8: 895 ms.
testDataViewGetUint16: 889 ms.
testDataViewGetInt32: 888 ms.
testDataViewGetFloat64: 890 ms.
meaning we lost around 10% on the single byte case, but gained 10% across
the board for all the other element sizes.
Design-Document: http://bit.ly/turbofan-word64
Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83
Reviewed-on: https://chromium-review.googlesource.com/c/1303732
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57095}
This reverts commit bf3d7b9ae3.
Reason for revert: Breaks TSAN build, see
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/23248
Original change's description:
> [wasm] Store compile errors in CompilationState
>
> We are currently storing compilation errors in the individual
> compilation units and pass it to the ErrorThrower during finishing.
> This CL changes that to store errors on the CompilationState directly.
> From there, it is propagated to the ErrorThrower in the compilation
> state callback.
> This removes more work from the finisher task and slims down the
> WasmCompilationUnits.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8343, v8:7921
> Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
> Reviewed-on: https://chromium-review.googlesource.com/c/1303720
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57091}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: Id32c7337494a4749485adbcfcaae7b2331afea66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8343, v8:7921
Reviewed-on: https://chromium-review.googlesource.com/c/1304544
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57094}
As the wasm compilation pipeline skips the start and end phase of
normal pipelines, we do not log compilation start/end for functions,
which makes reading log output more complicated than need be.
Change-Id: I1566ab7428b2dd9763c443000e946d4c6c789626
Reviewed-on: https://chromium-review.googlesource.com/c/1304540
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57093}
This removes more parameters which can be queried from the NativeModule.
R=titzer@chromium.org
Bug: v8:8343
Change-Id: Ia5111a336e8e2272f189ff2c5523afec8b2de660
Reviewed-on: https://chromium-review.googlesource.com/c/1303723
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57092}
We are currently storing compilation errors in the individual
compilation units and pass it to the ErrorThrower during finishing.
This CL changes that to store errors on the CompilationState directly.
From there, it is propagated to the ErrorThrower in the compilation
state callback.
This removes more work from the finisher task and slims down the
WasmCompilationUnits.
R=mstarzinger@chromium.org
Bug: v8:8343, v8:7921
Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
Reviewed-on: https://chromium-review.googlesource.com/c/1303720
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57091}
For NumberMin and NumberMax we don't need to go to Float64 when the
inputs are known to be in SafeInteger range, instead we can go to
Word64 on 64-bit architectures. This is preliminary work for the
huge DataView support, since we'll utilize NumberMax in that case
to clamp the limit for the bounds check.
Bug: v8:8178, v8:8383
Change-Id: I414114229c5c86b92749d30d645cedc641541ae4
Reviewed-on: https://chromium-review.googlesource.com/c/1304535
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57090}
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 fixes the fall-back case when parsing a multiplicative expression
where the lookahead found a '-' token followed by an unsigned token, but
no '*' token is following. We cannot rewind both tokens, but still need
to make sure that a full multiplicative expression is parsed.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-8377
BUG=v8:8377
Change-Id: I20ce6267445b32bdaf03f41f11d9ef4be66cb636
Reviewed-on: https://chromium-review.googlesource.com/c/1304317
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57084}
The Counters are not specific to compilation units, they just happen to
be used in WasmCompilationUnit::ExecuteCompilation.
Remove it from the compilation unit and pass it explicitly where needed.
This saves another field on the compilation units.
R=titzer@chromium.org
Bug: v8:8343
Change-Id: Iad4fd8ae23b022c237535503e0e805db7e67071a
Reviewed-on: https://chromium-review.googlesource.com/c/1304297
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57083}
The bug was that PreParser detected a stack overflow and an unidentifiable
error, and we tried to re-parse the same code. However, the stack overflow flag
was still set, and that messed up error handling in the Parser.
BUG=chromium:899495
Change-Id: Icdef74bdb8be252d75f245e243e1303ffb822ce2
Reviewed-on: https://chromium-review.googlesource.com/c/1304316
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57082}
- Store dirty JSWeakFactories in a heap root (not native context) -
during GC there's no native context necessarily.
- Schedule one microtask per JSWeakFactory.
- Enter the context of the cleanup function before calling it.
BUG=v8:8179
Change-Id: Icaa245a08a60dd7325af828858ebe55d842c5bf6
Reviewed-on: https://chromium-review.googlesource.com/c/1298899
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57081}
Move some methods to transitions-inl.h to avoid using methods defined
in other inl headers.
R=verwaest@chromium.org
Bug: v8:7965
Change-Id: I0f5a97ffa4c5faad1687c1586ef2dbf5193939bb
Reviewed-on: https://chromium-review.googlesource.com/c/1303299
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57080}
They are only needed in the async DecodeModule step. We can just store
a raw pointer to the Counters there.
R=mstarzinger@chromium.org
Bug: v8:8238
Change-Id: I2b22008fc4cbf6f8f69c9d53822fdb5af7d638f6
Reviewed-on: https://chromium-review.googlesource.com/c/1303302
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57078}
See discussion after this CL: https://crrev.com/c/1297960
We want to avoid the link from NativeModule to WasmEngine to enforce
encapsulation. If someone needs access to the WasmEngine, we should
give them a direct pointer.
R=titzer@chromium.org
Bug: v8:8217
Change-Id: I5bb6f4bf9b56c43085786d7092151d51bd0ff3ca
Reviewed-on: https://chromium-review.googlesource.com/c/1304433
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57076}
This allows very large arrays being joined to incrementally,
on-demand allocate the internal buffer. Previously, join
would allocate the buffer upfront and all at once. Large,
sparse arrays will use less memory.
Bug: chromium:897404
Change-Id: Id914b14a7c55a62834f63ad602bdb45363249075
Reviewed-on: https://chromium-review.googlesource.com/c/1303538
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57075}
Fix by removing a method with a single user instead of introducing an
inl-header.
R=mstarzinger@chromium.org
Bug: v8:7965
Change-Id: I596a673f36c63197db3e774d24b65abe01e83399
Reviewed-on: https://chromium-review.googlesource.com/c/1303717
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57071}
allocation-builder.h was using methods defined in map-inl.h, which is
not allowed. Thus move the respective methods to
allocation-builder-inl.h.
R=mstarzinger@chromium.org
Bug: v8:7965
Change-Id: Idd040f624d7e9491bc3d4bbd1e6ab3e8cf051917
Reviewed-on: https://chromium-review.googlesource.com/c/1303297
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57069}
and make it Isolate-independent.
Bug: v8:8238
Change-Id: I23faae87c302d24877ef001873f673d4a1cdd327
Reviewed-on: https://chromium-review.googlesource.com/c/1301484
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57066}
Now that embedded builtins are enabled everywhere*, lazy
deserialization can be turned off and removed.
* Except nosnap builds, on aix and in msvc builds.
Bug: v8:6666, v8:6624, v8:7990
Change-Id: Ib5fefe10e7ff35b13a1eb803fbc3736b8851b22b
Reviewed-on: https://chromium-review.googlesource.com/c/1288638
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57064}
While not strictly necessary, this is consistent with how
SlowFlagGetter behaves. It adds an additional shift operation (which
we could fold into the smi untagging if needed).
Drive-by: Typify flag accessors.
Bug: chromium:899464
Change-Id: Ib154d626e522ed723e2c19b1ab7f68560ac414bc
Reviewed-on: https://chromium-review.googlesource.com/c/1304315
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57063}
Node.js uses the tick processor as well, but wraps the script
differently so that `this.arguments` does not work.
Also fixed outdated comments.
R=petermarshall@chromium.org
Change-Id: Ia902962b302ec4aa02d31a6ac31ac20510ddcca7
Reviewed-on: https://chromium-review.googlesource.com/c/1304353
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57061}
When replacing a LoadElement with variable index with its known fields,
only do it if the types match, otherwise we end up with a graph that
representation selection cannot handle. That can only happen in dead
code, but TurboFan would nevertheless crash in representation selection.
Bug: chromium:893982, chromium:899524, v8:5267, v8:6200
Change-Id: I01e645d5e01bffb911d216d37d923792d9d0beab
Reviewed-on: https://chromium-review.googlesource.com/c/1303721
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57059}
This reverts commit ea8aa6a7c7.
Reason for revert: Breaking V8 Win64 - debug build, see
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25531
Original change's description:
> [parser] Set all tokens to ILLEGAL on parser error
>
> Otherwise already peeked tokens will possibly pass later checks causing us to
> parse more than necessary. Initially we held off on doing this since subsequent
> Consume calls would fail after previous checks succeeded; especially in the
> case of stack overflow. However, we've previously relaxed that DCHECK to also
> pass if the parser has an error.
>
> Change-Id: I413dffd475982d07299a08270fa94fdc3858e883
> Reviewed-on: https://chromium-review.googlesource.com/c/1304313
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57054}
TBR=marja@chromium.org,verwaest@chromium.org
Change-Id: Ifddd3cefa3876ec03aa1c137dfa95da3d933532e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1304295
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57057}
These two headers can be included in isolation currently, so no need to
exclude them.
R=marja@chromium.org
Bug: v8:7965
Change-Id: I6250a237e6884bc3f89e666bca5d8f4129472fe6
Reviewed-on: https://chromium-review.googlesource.com/c/1303715
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57056}
