With the arrival of generic structs (https://chromium-review.googlesource.com/c/v8/v8/+/1714868) the existing type inference procedure for generic calls became incomplete, since it could not infer types that were only constrained as part of generic types. For instance, given
struct Box<T: Type> { ... }
macro unbox<T: type>(box: Box<T>): T
the type argument (Smi) at the following call site
const box: Box<Smi> = ...;
unbox(box);
could not be inferred.
This CL re-implements the inference procedure and documents the semantics of type argument inference in Torque a bit more clearly.
R=tebbi@chromium.org
Change-Id: I868f16afbd9864b9c810ac49bc1639b467df939c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720812
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63005}
Removes static modifier from global inline functions defined in
globals.h.
R=rmcilroy@chromium.org
Bug: v8:9396
Change-Id: Ieacbcbf592d219fb50ab2d23dfbaba27246fb7ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728610
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63004}
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend
doesn't emit unwinding info and also because it doesn't emit ABI compliant
stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and
documented below:
https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0
This problem can be fixed similarly for Windows ARM64 by observing that V8
frames usually all have the same prolog which maintains a chain via frame
pointer (fp or x29 register).
stp fp, lr, [sp, ...]
One exception is JSEntry which stops fp pointer chain and needs to be handled
specially.
So it is possible to define XDATA with UNWIND_CODE which specify how Windows
should walk through V8 dynamic frames. The same as X64, since V8 Code objects
are all allocated in the same code-range for an Isolate, it is possible to
register at most 2 XDATA and a group of PDATA entries to cover stack walking
for all the code generated inside that code-range. This is more than 1
PDATA/XDATA because according to the Windows ARM64 exeption handling document,
1 PDATA can cover less than 1MB code range (see below doc).
https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling
This PR implements stackwalk for Windows ARM64 to be on par with X64, including
embedded builtins, jitted code and wasm jitted code, but not including register
handler for handling exception only, because there is no backward compatibility
to maintain for Windows ARM64 which was released since 1709 windows build.
Bug: chromium:893460
Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63002}
The s390 port uses the auxvector APIs to detect hardware/OS
support for various z/Architecture features. These checks
only make sense if we are running native, non-simulator mode.
Moving the include<auxv.h> under V8_HOST_ARCH_S390 enables
compilation of s390 simulation on platforms that do not have auxv.h
header available.
R=miladfar@ca.ibm.com,jyan@ca.ibm.com
Change-Id: I685681a4f8786509beb181d8ae63876b3a4235b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726844
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Joran Siu <joransiu@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62999}
port 556e485https://crrev.com/c/1669687
Original Commit Message:
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: Ic178de717d27a63b3f510b3a93e8f33a1730dc8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725669
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#62998}
REX prefix should be after mandatory prefix and before opcode.
Change-Id: I9829384d7d617d3be203026ae84ffa30aaef6d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726983
Commit-Queue: Bill Budge <bbudge@chromium.org>
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62997}
Original CL:
> [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}
R=ahaas@chromium.org, clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I03aa901a1df65af28f864d9aabe2b134ea132e99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724213
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62996}
The DCHECK related to a time when dictionary mode prototypes were the payload
of complex data driven handlers. Now the additional data is used to hold
entirely different kinds of objects. The DCHECK made no sense anymore. Cleaning
up the names makes this clearer.
Bug: chromium:986187
Change-Id: I7173d7d2824396c04c01acb4ceb74693ee9ce6b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724215
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62993}
D8 workers were leaking all messages due to a missing HandleScope
within the message loop. Add one to fix leaks.
R=verwaest@chromium.org
BUG=v8:9524
Change-Id: I2f2f6ba0b8c58bf38bf68b7464dffdf1d826a29d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724212
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62992}
Do not pass the deoptimization index in a register, instead infer it
from the address we made the deoptimization call from. This makes the
deoptimization exit sequence one instruction long instead of two.
This requires emitting all deoptimization exits at the end of the
function in a contiguous block, making sure no constant or veneer
pools are emitted in between. This means that soft deoptimizations
require an additional branch to the end of the function, which
counteracts the removal of the move instruction, however soft
deoptimizations are rare compared to eager and lazy ones.
This reduces the code size of optimised functions for benchmarks like
Octane and ARES-6 by about 4%.
Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62991}
This method will be used for a test with multiple code spaces, to
encode large function indexes. The current implementation in
{wasmI32Const} just always uses 5 bytes for encoding the LEB value.
This CL adds a {wasmSignedLeb} function which properly encodes the
value, and adds tests for that.
Drive-by: Clean up the rest of {test-wasm-module-builder.js}.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ide2d90eed9d40aa28df680fbb413275346d9c0b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725623
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62990}
iOS still uses the recipe-side toolchain, so calling the mac_toolchain
script on src-side is useless in iOS checkouts.
Bug: chromium:986701
Change-Id: I1252d01088eca69e6b465c30856f9434eea99aab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725612
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62989}
This patch adds:
- VariableMode::kPrivateMethod
- VariableMode::kPrivateSetterOnly
- VariableMode::kPrivateGetterOnly
- VariableMode::kPrivateGetterAndSetter
And replace the previous RequiresBrandCheckFlag by inferring
whether the brand check is required from these VariableModes.
It is then possible to check duplicate non-complementary
accessors in the parsers and throw early errors, and allow
complementary accessors to be associated with the same
private name variable.
This patch also adds the following AssignType:
- PRIVATE_METHOD
- PRIVATE_GETTER_ONLY
- PRIVATE_SETTER_ONLY
- PRIVATE_GETTER_AND_SETTER
corresponding to the new VariableModes so that it's possible
to generate specialized code for different type of
private accessor declarations.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62988}
The tests rely too much on OS state (thread allocation) to be
predictable.
Change-Id: I9a562369a3c72522630a23ee47e3e819b9411c65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725626
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62987}
On Windows, the FP stack registers are used with less precision.
This causes rounding errors in the uint64 to float32 conversion.
This CL replaces the implementation based on FP stack registers
with an implementation based on bit operations. This implementation
is 2x slower than the original implementation.
An alternative would be to change the precision of the FP stack
registers just for the uint64 to float32 conversion. However, in a
micro-benchmark this is 5-6x slower than the original implementation.
It is also not clear if changing the precision could cause side
effects.
R=clemensh@chromium.org
Change-Id: Iaab6b6f258ff01e0c6e93f3632daf516fae3e74b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708486
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62986}
Previously, this was run as a microtask and this CL changes it to run
as a separate task as mandated by the current WeakRef spec.
This CL also introduces a FinalizationGroup type to the V8 API
representing the JSFinalizationGroup. This has a `Cleanup`
function that runs the cleanup callback associated with it.
SetHostCleanupFinalizationGroupCallback is added to set
the embedder defined HostCleanupFinalizationGroupCallback.
ClearKeptObject is exposed on the v8::Isolate to reset the strongly
held set of objects.
The general workflow is the following:
(a) When the GC notices that a given finalization group has dirty
cells, it calls HostCleanupFinalizationGroupCallback with the given
finalization group.
(b) As part of HostCleanupFinalizationGroupCallback, the embedder
enqueues a task that at some point later calls
FinalizationGroup::Cleanup.
(c) At some point in the future, FinalizationGroup::Cleanup is called,
which runs the cleanup callback of the finalization group.
This patch also includes d8 changes to use these new APIs. Currently,
d8 cycles through the enqueued finalization groups after a synchronous
turn (and it's microtask checkpoint) and runs the cleanup callbacks.
Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc
Bug: v8:8179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62984}
This drops possible remaining pattern errors from the access target. This is
necessary since sub patterns with default values (assignment expression) aren't
otherwise identifiable as being property accesses.
Bug: v8:9560
Change-Id: Ie6781c0d161e00790268f7d9db81377d045f93b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725624
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62982}
FLAG_max_semi_space_size could be used to allow arbitrarily huge semi
spaces. Limit semi space size to kMaxSemiSpaceSize also in the case
this flag is used.
Change-Id: Id52cea6ef73eb1957265cf38c109dd490d7feccc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725618
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62980}
This allows to return bool values from Torque macros and branch on them
without performance penalty, reconstructing good control flow.
Drive-by cleanup: Delete EnsureDeferredCodeSingleEntryPoint(), since
it's no longer needed. Constructing a graph and then re-inferring
deferred blocks based on branch hints achieves this effect
automatically.
Bug: v8:7793
Change-Id: Idb6802372b407549e4760f290933d5b8f1e9d952
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681132
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62979}
Object::Get, Set, etc. properly invoke an interceptor
registered via SetAccessCheckCallbackAndHandler, however,
Object::GetOwnPropertyDescriptor does not invoke
an interceptor.
This patch supports access-check-interceptor for
descriptors.
Change-Id: Ie2b2f2456be95c6eef8c2cdfee2bdd651c011fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720969
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62978}
This reverts commit 4b15b984ad.
Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0).
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> 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}
TBR=jgruber@chromium.org,seth.brenith@microsoft.com
Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9305
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62977}
Currently, each single CSA_ASSERT invokation creates its own lambda,
which is then wrapped in a {std::function} and passed to
{CodeStubAssembler::Assert}. It takes a lot of compile time for clang
to generate all the code for that.
This CL introduces a more light-weight alternative to
{CodeStubAssembler::Assert} which just receives the node directly.
This reduces compile time of {code-stub-assembler.cc} in optdebug mode
from ~30 seconds to ~17 seconds locally.
R=tebbi@chromium.org
Bug: v8:7629
Change-Id: I4520a7b587cb96319d75048cf11c1124be583d6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724370
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62976}
This fixes a build failure for arm64 on Windows.
Bug: v8:9564
Change-Id: I845b7687379ae12c27fa2924775553c83dc5d1ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724386
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62975}
This is a reland of a0728e869b
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}
Bug: v8:9524
Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62974}
We can get repeated positions from optimized code objects in some cases
but for our purposes of looking up a line number from a PC, we can only
return one line number so just use the first one that is reported in
the source position table on the code object.
Change-Id: I4c0e866fb1948f65bf6c988d992ef55f520dd874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724375
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62972}
-0.0 and 0.0 compare equals, so a < b ? a : b for min would pick b
incorrectly. We need to use JS semantics here, which returns -0.0.
Bug: v8:8425
Change-Id: I8ab094b566ece9c586de86aad4594dfdf8da930b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724802
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62969}
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}
