Serialize for all cases of JSNativeContextSpecialization::ReduceJSInstanceOf.
Bug: v8:7790
Change-Id: I147991353b86619808257a92961b7051105511f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722558
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62965}
Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
change is inspired by attempting to exit earlier from generated RegExp
code, when no further matches are possible because any match would be
too long. The motivating example this time is the following expression,
which tests whether a string of Unicode playing cards has five of the
same suit in a row:
/([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
A human reading this expression can readily see that any match requires
at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
each repeated option reports its minimum distance to the end of a match
as zero. This is correct, because the LoopChoiceNode's behavior depends
on additional state (the loop counter). However, the preceding node, a
SET_REGISTER action that initializes the loop counter, could confidently
state that it consumes at least 10 characters. Furthermore, when we try
to emit a quick check for that action, we could follow only paths from
the LoopChoiceNode that are possible based on the minimum iteration
count. This change implements both of those "could"s.
I expect this improvement to apply pretty broadly to expressions that
use minimum repetition counts and that don't meet the criteria for
unrolling. In this particular case, I get about 12% improvement on the
overall UniPoker test, due to reducing the execution time of this
expression by 85% and the execution time of another similar expression
that checks for n-of-a-kind by 20%.
Bug: v8:9305
Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62963}
Fixes a bytecode mismatch for arrow functions with default arguments
between eager and lazy compilation. In the former case, parameters with
default values are marked as assigned even if the value never changes
within the function because the parser does not know it's an
arrow-function at the point it sees the assignment.
So this changes ArrowHeadParsingScope::ValidateAndCreateScope to clear
the is_assigned flag on its parameter VariableProxies before it binds
them.
Bug: chromium:988304, v8:8510
Change-Id: I68bf205c73471386181e5fdcec6c8c3b2e527c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724384
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62962}
Instead of storing the values of the single precision floating point registers,
get their values from the aliased double precision registers.
This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total)
and 128 bytes in the RegisterValues class.
Change-Id: I681ad46efbb610e94d1e45871e012d2c0a3cfa3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669687
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62961}
This is a reland of 658ff20085
Original change's description:
> [utils] Make BitField final
>
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
>
> Before:
> class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
> using MyBitField = BitField<int, 6, 4, MyEnum>;
>
> This might reduce compilation time by reducing the number of existing
> classes.
>
> The old pattern is forbidden now by making {BitField} final.
>
> R=yangguo@chromium.org
>
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}
Bug: v8:9396, v8:7629
Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62959}
This reverts commit 658ff20085.
Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
Original change's description:
> [utils] Make BitField final
>
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
>
> Before:
> class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
> using MyBitField = BitField<int, 6, 4, MyEnum>;
>
> This might reduce compilation time by reducing the number of existing
> classes.
>
> The old pattern is forbidden now by making {BitField} final.
>
> R=yangguo@chromium.org
>
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}
TBR=yangguo@chromium.org,clemensh@chromium.org
Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396, v8:7629
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62958}
We have hundreds of classes that derive from {BitField} without adding
any functionality. This CL switches all such occurrences to 'using'
declarations instead.
Before:
class MyBitField : public BitField<int, 6, 4, MyEnum> {};
After:
using MyBitField = BitField<int, 6, 4, MyEnum>;
This might reduce compilation time by reducing the number of existing
classes.
The old pattern is forbidden now by making {BitField} final.
R=yangguo@chromium.org
Bug: v8:9396, v8:7629
Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62956}
Prefer using the wasm engine's allocator, as the isolate may not be
available during asynchronous compilation.
Bug: v8:9554
Change-Id: Iee3777efb62d18de6b2a64fa7a71d4ef4c6b3a92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722559
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62955}
This makes function objects constructed via the {WebAssembly.Function}
constructor callable directly from JavaScript (not just from within
WebAssembly modules). Semantics are as if the function performed the
transition JS-to-Wasm and then Wasm-to-JS in sequence.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62953}
The preprocessor of MSVC works differently for empty __VA_ARGS__.
Another hack is needed to make this compile in both MSVC and clang.
R=tebbi@chromium.org
Bug: v8:9555
Change-Id: Ie8f2e1ed302730419dae95e49ab0cca35a4a8131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720669
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62952}
In export wrapper compilation, the isolate was used to get enabled
features. This prevents asynchronous compilation, so this is replaced
with an enabled_features argument passed from the main thread.
R=mstarzinger@chromium.org
Bug: v8:9554
Change-Id: Iab8a090841170dc235273dda58997cde716ee13f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722554
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62949}
Prior to this CL, the regexp fast path check is stricter than it
needs to be. For example, adding any arbitrary property on the regexp
prototype would move the execution of all regexp builtins in the same
context onto the slow path. This actually happens in the real world:
popular web frameworks commonly monkey-patch builtin prototypes to add
functionality.
The intent of this CL is to widen the fast path for regexp builtins s.t.
modifications of the prototype that do not conflict with our
requirements stay on the fast path.
This is done by extending the current fast path check with an
additional step. If checking the prototype map identity or
relevant prototype property constness fails, we now compare the actual
value of all relevant properties against the expected value. If these
match, the prototype can be considered fast.
The new step as described in the previous paragraph is part of the
permissive fast path check (BranchIfFastRegExp_Permissive). The strict
variant (BranchIfFastRegExp_Strict) is also still required by a few
spots. We should refactor these to also allow the permissive check in
follow-up work.
Bug: v8:5577,chromium:977382
Change-Id: I69b2244e68ccfbd00edf17fc326aa4b5f5d089fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706056
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62948}
This enables the recipe to set FORCE_MAC_TOOLCHAIN and decide if hermetic
or system xcode is used.
TBR=tmrts@chromium.org
Bug: chromium:986701
Change-Id: I2c1ba75d5d62e493bd9dc7a5ec5f7e40465d8f98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722557
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62947}
In export wrappers generated code, load the undefined value from the
wasm instance rather than from the isolate. With asynchronous
compilation, the isolate may not be available.
R=mstarzinger@chromium.org
Bug: v8:9554
Change-Id: Ic448bda82c2125fc9c9f8715bce26870308715d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722556
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62946}
Implements ProfilerCodeObserver, a class to track the generation and
movement of code on the heap for the lifetime of each CpuProfiler. When
sampling is inactive, logged code is committed directly to the CodeMap.
During profiling, ProfilerCodeObserver redirects these events onto the
profiling thread for later dispatch.
Bug: v8:9151
Change-Id: Ib5b152446d2a3838e1b00a80253fc4fbd2f6e8c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1604143
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#62943}
This change updates the RegExp bytecode generator to emit checks for
larger eats_at_least values when they are available, so we can fail to
match earlier in some cases.
Bug: v8:9305
Change-Id: I96740531e142ff8dced41c49b774845b07df6ae6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709768
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62942}
In some cases, we end up with a ChangeCompressedPointerToTaggedPointer next
to a CheckedTaggedToTaggedPointer. In this case, the checked one is not
needed since we are sure we are dealing with a pointer (and not a Smi).
This doesn't get resolved in the simplfied lowering phase due to having a
Phi[Tagged] in the middle of those two nodes.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: Ia4a44b36423c2242d5c663f9b93b09924190fe8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709426
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62941}
If we are sure that we are dealing with a Compressed value, we can check
for sminess in 32 bits.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: Icf77d8bcd1decfd392b4887241a9b559f11814c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718146
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62940}
This CL removes the built-in reference type in favor of a Torque-implemented generic struct, i.e., internal::Reference<T>. It also adds various infrastructure for getting and creating new generic struct instances, as well as matching against them.
R=tebbi@chromium.org
Change-Id: I1e3d6afe355a0603fa9c3ad789c6b8a97d1b3c26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718148
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62939}
The propagation of tenuring from outer allocations to inner allocations
was blocked in pointer compression since we now had Compress nodes between
AllocateRaw and StoreField.
This was causing issues in GC. It popped up in the Octane2.1/Splay
benchmark, where we had big regressions.
This CL updates the memory optimizer so that it can use the Compress nodes
as bridges and can perform the optimization successfully. Note that the
Compress nodes only appear on the value input of the StoreField.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703, v8:9519
Change-Id: I6b0cc67955c6cc696e8c426b85c87a1794098ed0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714650
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62938}
This reverts commit a0728e869b.
Reason for revert: Times out on Windows & debug builds - https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/34484
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org
Change-Id: I3a27937cba13b5413390f49268a107c184515153
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720590
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62937}
Use the position of commas in arrow expressions to mark the initializer
position of any parameters that might have been set in the preceding
parameter.
To enable this, this makes variable_list_ in ExpressionParsingScope a
ScopedList<pair<VariableProxy*, int>> and changes ScopedList::at to
return references so its elements can be modified in place.
This fixes a source of bytecode mismatches when collecting source
positions lazily and is a second attempt at fixing this after
https://chromium-review.googlesource.com/c/v8/v8/+/1683267 introduced
problems due to destructuring.
Bug: chromium:980422, chromium:981701, v8:8510
Change-Id: I948f89f34fb75d7463a13183e363f7f96ad09d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710671
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62936}
This reverts commit 1320c917dd.
Reason for revert: The code in SFI is also flushed by the serializer with FunctionCodeHandling::kClear, so this fix does not work with --no_flush_bytecode.
Original change's description:
> [snapshot] Fix clearing of feedback vector in serializer (follow-up 2)
>
> Bug: v8:7857
> Change-Id: I3940ae2830adb6c572e079551b7bba7d84462afd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715444
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62881}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7857
Change-Id: If85fe29b2cdf6523ee53895628da38d942d45c2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719190
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62935}
This is short-term fix for flaky failures on GC fuzzer. The closures
g1 and g2 have the same SFI and pending optimzed table treats them as
a single entry. This cl, adds %PrepareFunctionForOptimize after one of
them is optimized.
Bug: v8:9556
Change-Id: I1fd72da1baa5de2f7650e080f9b6d04b69dd6a16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719188
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62934}
This CL refactors the lifetime management of the v8::Worker C++ object
and in the process lifts the 100 maximum worker limitation. To do this,
it uses a Managed<v8::Worker> heap object and attaches the managed to
the API worker object.
R=mstarzinger@chromium.org
BUG=v8:9524
Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62932}
... mostly by turning them into pointer arguments.
After this CL, all remaining non-const reference arguments in
the compiler directory are in the backend.
Bug: v8:9429
Change-Id: I6a546da0fe93179e1a0b12296632591cbf209808
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719185
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62930}
This reverts commit 425fa3ae15.
Reason for revert: test failure https://bugs.chromium.org/p/v8/issues/detail?id=9554 reverting the root cause has merge conflicts due to changes in same file
Original change's description:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
> assuming the array was created with the correct size. This simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule() and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
TBR=binji@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I8dcad7ddcd4601f657b6263bf22009907284fce3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719230
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62926}
This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
The intent is to make the various ways of creating a module (sync,
async, deserialize, import) more similar.
After this change, a NativeModule will always be created before a
WasmModuleObject. This will make it easier to look up a cached
NativeModule given its wire bytes.
The following changes are made:
* Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
size estimate by default. A different code size estimate is only used in
tests.
* Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
assuming the array was created with the correct size. This simplifies
WasmModuleObject::New(), and matches what CompileToNativeModule()
does.
* Remove the WasmModuleObject::New() constructor that creates a
NativeModule. This case was only used in DeserializeNativeModule() and
in test code.
Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62925}
Data in the viewer has to be in the same order as the labels.
Change-Id: I2e64fb30ebc0e3585c7b9d364553cb6a5ec1f3cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718159
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62921}
- Move SerializePrototype out of DependOnStablePrototypes into
ComputePropertyAccessInfo.
- Brokerize JSNativeContextSpecialization::InferHasInPrototypeChain.
- Brokerize JSNativeContextSpecialization::ReduceJSOrdinaryHasInstance
(modulo the call to ReduceJSInstanceOf).
- Brokerize JSNativeContextSpecialization::ReduceJSHasInPrototypeChain.
- Serialize for JSCallReducer::ReduceObjectPrototypeIsPrototypeOf.
- Serialize for JSNativeContextSpecialization::ReduceJSInstanceOf. This
is still incomplete.
Bug: v8:7790
Change-Id: Ic56eab5ddd8d725a13d2980e5b55db53ae82e822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709408
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62920}
The motivating example is JetStream 2's UniPoker test, which tests
whether a sorted string of Unicode playing cards contains a five-card
straight using a regular expression. In the top-level generated loop for
this RegExp, we see this loop exit condition:
00000350000C2067 27 83fffe cmpl rdi,0xfe
00000350000C206A 2a 0f8da8e40000 jge 00000350000D0518 <+0xe4d8>
Meaning if the current position is pointing at the very last (16-bit)
character, then we exit the loop. Otherwise we go on and try to find
various matches starting at the current position. However, we can see
in the original expression that any possible match is at least 10
characters (5 astral-plane Unicode values), so we're wasting a lot of
time attempting to find matches in cases where we're too close to the
end of the string for any match to succeed.
This example might be a bit contrived, but I expect that an improvement
in this bounds check would help a larger family of regular expressions,
where the minimum match length is large relative to the string being
matched and we don't meet the other necessary criteria for fast Boyer-
Moore lookahead.
To get the desired bounds check in this case, this patch does the
following:
1. Compute accurate EatsAtLeast values for every node during the
analysis phase. This could end up doing more work than the current
implementation, but analysis already has to touch every node, so it
seems like a cache-friendly time to compute these values. In some
cases, this might be less total work than the current implementation,
because the current implementation might recompute the same node
multiple times.
2. When emitting a quick check, use the EatsAtLeast value from the
predecessor ChoiceNode for the bounds check.
This improves the UniPoker score on my machine by about 4%, because it
cuts the time spent checking for straights roughly in half, and checking
for straights originally accounted for about 8% of the total time.
Bug: v8:9305
Change-Id: I110b190c2578f73b2263259d5aa5750e921b01be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702125
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62919}
