This change adds test functions to check that the Torque-generated
verifiers can catch a few basic kinds of errors and crash the process.
Bug: v8:7793
Change-Id: If0d2b1e8834c3e602c2677253ad3a920566414bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469039
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70506}
This CL adds a basic tiering strategy for the js-to-wasm wrappers.
When applicable, calls to exported WebAssembly functions are initially
handled through the generic js-to-wasm wrapper. If these calls
through the generic wrapper reach a constant threshold, the specific
(per-signature) wrapper is compiled synchronously for the function
and the generic wrapper is replaced.
Bug: v8:10982
Change-Id: I65e706daffb5cb6e723ce2f7b785f7ecb7b2fa7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461243
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70503}
We fall back from irregexp to the experimental engine if a backtrack
limit is exceeded and the experimental engine can handle the regexp.
The feature can be turned on with a boolean flag, and an uint-valued
flag controls the default backtrack limit. For regexps that are
constructed with an explicit backtrack limit (API,
%NewRegExpWithBacktrackLimit), we choose the lower of the explicit and
default backtrack limits.
The default backtrack limit does not apply to regexps that can't be
handled by the experimental engine, and for such regexps an explicitly
specified backtrack limit is handled as before by returning null if we
exceed it.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70500}
This is a reland of 3593ee832c
The MSAN doesn't seem to be considering initializing stores via inline
assembly as such (in a new cctest helper GetStackPointer()), so this
reland attempt fixes the issue and ensures that the MSAN bot is happy.
Original change's description:
> Reland "[csa] Fix semantics of PopAndReturn"
>
> This is a reland of 5e5eaf7954
>
> This CL fixes the "function returns address of local variable" issue
> which GCC was complaining about by using inline assembly instead of
> address of a local for getting stack pointer approximation.
>
> Original change's description:
> > [csa] Fix semantics of PopAndReturn
> >
> > This CL prohibits using PopAndReturn from the builtins that
> > have calling convention with arguments on the stack.
> >
> > This CL also updates the PopAndReturn tests so that even off-by-one
> > errors in the number of poped arguments are caught which was not the
> > case before.
> >
> > Motivation:
> >
> > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> > dropping ALL JS arguments that are currently located on the stack.
> > Disallowing PopAndReturn in builtins with stack arguments simplifies
> > semantics of this instruction because in case of presence of declared
> > stack parameters it's impossible to distinguish the following cases:
> > 1) stack parameter is included in JS arguments (and therefore it will
> > be dropped as a part of 'pop' number of arguments),
> > 2) stack parameter is NOT included in JS arguments (and therefore it
> > should be dropped in ADDITION to the 'pop' number of arguments).
> >
> > This issue wasn't noticed before because builtins with stack parameters
> > relied on adapter frames machinery to ensure that the expected
> > parameters are present on the stack, but on the same time the adapter
> > frame tearing down code was effectively recovering the stack pointer
> > potentially broken by the CSA builtin.
> >
> > Once we get rid of the arguments adapter frames keeping stack pointer
> > in a valid state becomes crucial.
> >
> > Bug: v8:5269, v8:10201
> > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70454}
>
> Tbr: tebbi@chromium.org
> Bug: v8:5269
> Bug: v8:10201
> Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70483}
Tbr: tebbi@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Bug: v8:5269
Bug: v8:10201
Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70492}
As a drive-by, enable tests that are safe for Arm32/64 to run.
Bug: v8:10833
Change-Id: I8fed5651399852f9ce8ba7d5acdb7ed27ca28e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467841
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70491}
This reverts commit 3593ee832c.
Reason for revert: MSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34798
Original change's description:
> Reland "[csa] Fix semantics of PopAndReturn"
>
> This is a reland of 5e5eaf7954
>
> This CL fixes the "function returns address of local variable" issue
> which GCC was complaining about by using inline assembly instead of
> address of a local for getting stack pointer approximation.
>
> Original change's description:
> > [csa] Fix semantics of PopAndReturn
> >
> > This CL prohibits using PopAndReturn from the builtins that
> > have calling convention with arguments on the stack.
> >
> > This CL also updates the PopAndReturn tests so that even off-by-one
> > errors in the number of poped arguments are caught which was not the
> > case before.
> >
> > Motivation:
> >
> > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> > dropping ALL JS arguments that are currently located on the stack.
> > Disallowing PopAndReturn in builtins with stack arguments simplifies
> > semantics of this instruction because in case of presence of declared
> > stack parameters it's impossible to distinguish the following cases:
> > 1) stack parameter is included in JS arguments (and therefore it will
> > be dropped as a part of 'pop' number of arguments),
> > 2) stack parameter is NOT included in JS arguments (and therefore it
> > should be dropped in ADDITION to the 'pop' number of arguments).
> >
> > This issue wasn't noticed before because builtins with stack parameters
> > relied on adapter frames machinery to ensure that the expected
> > parameters are present on the stack, but on the same time the adapter
> > frame tearing down code was effectively recovering the stack pointer
> > potentially broken by the CSA builtin.
> >
> > Once we get rid of the arguments adapter frames keeping stack pointer
> > in a valid state becomes crucial.
> >
> > Bug: v8:5269, v8:10201
> > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70454}
>
> Tbr: tebbi@chromium.org
> Bug: v8:5269
> Bug: v8:10201
> Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70483}
TBR=tebbi@chromium.org,ishell@chromium.org,victorgomes@chromium.org
Change-Id: Icbd71d744a519a58e49feb917109228631b9d9a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467846
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70485}
This is a reland of 5e5eaf7954
This CL fixes the "function returns address of local variable" issue
which GCC was complaining about by using inline assembly instead of
address of a local for getting stack pointer approximation.
Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
> be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
> should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}
Tbr: tebbi@chromium.org
Bug: v8:5269
Bug: v8:10201
Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70483}
Currently there are a number of -Wsubobject-linkage warnings when
compiling with gcc (formatted to fit 72 character lines):
In file included from
...
from ../../testing/gtest/include/gtest/gtest.h:10,
from ../../testing/gtest-support.h:8,
from ../../test/unittests/test-utils.h:20,
from ../../test/unittests/compiler/backend/
instruction-selector-unittest.h:15,
from ../../test/unittests/compiler/x64/
instruction-selector-x64-unittest.cc:9:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:
In instantiation of ‘class
testing::internal::ParameterizedTestFactory<v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>’:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:439:12: required from
‘testing::internal::TestFactoryBase*
testing::internal::TestMetaFactory<TestSuite>::CreateTestFactory(
testing::internal::TestMetaFactory<TestSuite>::ParamType)
[with
TestSuite = v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test;
testing::internal::TestMetaFactory<TestSuite>::ParamType =
v8::internal::compiler::{anonymous}::LoadWithToInt64Extension]’
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:438:20: required from here
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:394:7: warning:
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test >’ has a field
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>::parameter_’ whose type uses the
anonymous namespace [-Wsubobject-linkage]
394 | class ParameterizedTestFactory : public TestFactoryBase {
| ^~~~~~~~~~~~~~~~~~~~~~~~
This commit moves the parameterized tests in question into the
anonymous namespace to avoid the warnings.
Change-Id: I9c4a8bd9f4e225ed14ab64f5433d5f5c102e01a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418723
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70482}
Whenever more then one value is pushed to the stack, we need to execute
a check for growing the stack first (since https://crrev.com/c/2431525).
This CL adds two missing checks.
R=thibaudm@chromium.org
Bug: chromium:1137582
Change-Id: I9755502dfdb77c03d1dde3e83fb7d33b9b99e499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467796
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70480}
The call to "GetSpilledRegistersForInspection" was invalidated by the
call to "GetUnusedRegister" a few lines below.
R=clemensb@chromium.org
Bug: v8:10957
Change-Id: I1e0110d9b28ca23a2a8b9ff4b4c39143bfbe5510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466118
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70478}
The index to be traced can be a full (platform-dependent) pointer sized
integer now. This CL prepares memory tracing for that.
As a drive-by, the "address" field is renamed to "offset", or
"effective_offset", depending on the situation.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I1fabfdb57835f041e1310a4eb4024d6254c08752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465825
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70477}
Rename the flag --liftoff-extern-ref to
--experimental-liftoff-extern-ref to keep the fuzzer from using it.
The implementation is not complete yet, and the next steps may take a
bit.
R=clemensb@chromium.org
Bug: chromium:1137601
Change-Id: I74f1ed8faba44e42f63790d87f4a538dd59ac852
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465838
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70476}
Use monotonic times for logging with --predictable.
Bug: v8:10937, v8:10966, v8:10668
Change-Id: I3d4f0d48375f6f5d9fa375cf5393ff3afee7c0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465829
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70474}
We now remember whether the memory was 64 bit, in in this case force the
index value to be an i64 instead of an i32.
This is only the decoding part of this change. TurboFan and Liftoff will
have to be fixed separately to handle the i64 values correctly.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ia504e7eb5a2a55caf8dfdbd0833481ef590c55bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461239
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70473}
The generic wrapper will be the baseline variant of the JavaScript-to-
WebAssembly wrapper. Enabling it in the nooptimization variant gives it
test coverage.
R=clemensb@chromium.org
Bug: v8:10701
Change-Id: I37d1f767c61ff70e103d1742ef84f874c3804d7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461240
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70472}
Always spend 1ms per iteration.
Previously if the profilerthread took a long time to start up then we
would skip through iterations and potentially not gather enough samples.
This forces each iteration to take 1ms.
Bug: v8:10996
Change-Id: I0dd7bb7e31636c9ebf5dd99110c8a976cbc8f045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461727
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70466}
CreateFrameFromInternal always creates StackFrame from the frame at the index zero,
which is fine for the usage in Trap::origin, but is a bug for Trap::trace
Change-Id: Ia9471f600c5165ffc1c165b2f114b40acbe5b1e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465353
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70465}
These are still not in proposal, so they should be behind the post-mvp
flag.
Bug: v8:10972
Change-Id: I1b53307f334ddd8e21a095c13d7f7abb8ce05203
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465654
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70463}
This implements i8x16.popcnt on arm64 and interpreter.
Bug: v8:11002
Change-Id: Ia94a053d7e0a0c800057ac80865ba6f86ac7caf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461058
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70461}
This reverts commit 5e5eaf7954.
Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929?
Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
> be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
> should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}
TBR=tebbi@chromium.org,ishell@chromium.org
Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70458}
Load lane loads a value from memory and replaces a single lane of a
simd value.
This implements the load (no stores yet) for x64 and interpreter.
Bug: v8:10975
Change-Id: I95d1b5e781ee9adaec23dda749e514f2485eda10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444578
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70456}
These instructions are not in the proposal, and will be unlikely to be
requested (poor performance, insufficient use cases). As we get more
instruction suggestions, these are sitting around on useful opcodes and
we have to play musical chairs every time we prototype a new
instruction.
Bug: v8:10933
Change-Id: Ic7ce4e514c343d821f76b8c071e41f9bddfbd1ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2457669
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70455}
This CL prohibits using PopAndReturn from the builtins that
have calling convention with arguments on the stack.
This CL also updates the PopAndReturn tests so that even off-by-one
errors in the number of poped arguments are caught which was not the
case before.
Motivation:
PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
dropping ALL JS arguments that are currently located on the stack.
Disallowing PopAndReturn in builtins with stack arguments simplifies
semantics of this instruction because in case of presence of declared
stack parameters it's impossible to distinguish the following cases:
1) stack parameter is included in JS arguments (and therefore it will
be dropped as a part of 'pop' number of arguments),
2) stack parameter is NOT included in JS arguments (and therefore it
should be dropped in ADDITION to the 'pop' number of arguments).
This issue wasn't noticed before because builtins with stack parameters
relied on adapter frames machinery to ensure that the expected
parameters are present on the stack, but on the same time the adapter
frame tearing down code was effectively recovering the stack pointer
potentially broken by the CSA builtin.
Once we get rid of the arguments adapter frames keeping stack pointer
in a valid state becomes crucial.
Bug: v8:5269, v8:10201
Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70454}
For turboprop, it's a better tradeoff to reuse the code than
specialising the code for a particular closure especially given we
optimize quite early when compared to Turbofan.
Bug: v8:9684
Change-Id: Icf5d8548bbdcac9e202dcf44c68e06cc4c732ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461242
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70451}
This test allocates a large mapping and splits into kThunkBufferSize
areas that it needs to be able to change permissions on. So
kThunkBufferSize needs to be set to the largest page size possible,
which is 64k at the moment.
It doesn't matter if kThunkBufferSize is larger than the actual page
size.
Bug: v8:10808
Change-Id: I3a8947f04a7ec25be49a54015cd128e901065ea6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463404
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70449}
Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.
Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.
Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.
This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.
Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464823
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}
Clean-ups:
* Remove the detaching of persistent handles from the LocalHeap if the
main thread will not get the handles from the background thread.
* Remove unused isolate member.
* Make members private/protected as needed.
Bug: v8:7790
Change-Id: I23bf4a41124bd04d4a848edfa1ef8f9e8e77182c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463234
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70442}
This is a reland of e2408c2521
Changes since last time: also accept CRASH test results. For some
reason, the CHECK failure is detected as a CRASH on mac bots.
Original change's description:
> [regexp] Protect against reentrant RegExpStack use
>
> Irregexp, and in particular the RegExpStack, are not reentrant.
> Explicitly guard against reentrancy.
>
> Bug: chromium:1125934
> Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70436}
Tbr: yangguo@chromium.org
Bug: chromium:1125934
Change-Id: I2116ca5944c49f6114228d4402847bdd426bdd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465823
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70441}
Irregexp, and in particular the RegExpStack, are not reentrant.
Explicitly guard against reentrancy.
Bug: chromium:1125934
Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70436}
These tests were disabled because scalar lowering wasn't fully
implemented yet. Now we are at a stage when we can enable them.
The only remaining tests with lowering test disabled are prototype
instructions, once they are merged into the proposal proper, scalar
lowering should be implemented for them, and relevant tests enabled.
Bug: v8:10507
Change-Id: I4b7c8778f70e226ebda3bf5a2a7dd5efa343bc0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460841
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70435}
Lowering for f32x4 and f64x2 pmin and pmax.
Bug: v8:10501,v8:10507
Change-Id: I2d92d337835a62e6adb979ed573b616cc2b86c25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461453
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70434}
Some of these functions don't need to be defined, we can directly call
the same helpers defined elsewhere.
Bug: v8:10933
Change-Id: I31464195b11ed14f0725d9ed9711fa72ddbb4e92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461478
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70433}
Tracing JSMembers uses the bailout mechanism.
The bailout is implemented as a dynamic mechanism named
DeferTraceToMutatorThreadIfConcurrent that is called from
relevant Trace methods.
Bug: chromium:1056170
Change-Id: I90e6feae25c4c832be256693f9e44a963a6794b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426613
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70429}
Adds a cross-thread reference for strongly and weakly retaining
objects on a thread other than the thread that owns the object.
The intended use of the reference is by setting it up on the
originating thread, holding the object alive from another thread, and
ultimately accessing the object again on the originating thread.
The reference has known caveats:
- It's unsafe to use when the heap may terminate;
- It's unsafe to transitively reach through the graph because of
compaction;
Change-Id: I84fbdde69a099eb54af5b93c34e2169915b17e64
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436449
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70428}
Since GC can now happen during deserialization, object fields may
contain the Smi sentinel value instead of pointers. This adds the
required guards to methods of NativeContextInferrer
Bug: chromium:1136801
Change-Id: I7338f31bf6ee34b8dee8431b8250d2cc2978e0c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461241
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70425}
Changes:
- Add wasm-to-js wrapper field to WasmJSFunction. A WasmJSFunction might
be called with call_ref without being imported to a module, and this
provides a call target for this scenario. The wrapper is only compiled
if --experimental-wasm-typed-funcref is set.
- Add CompileWasmToJSWrapper in wasm-compiler.
- Rename BuildLoadFunctionDataFromExportedFunction ->
BuildLoadFunctionDataFromJSFunction to reflect its wider usage.
- Rename BuildWasmImportCallWrapper -> BuildWasmToJsWrapper to reflect
this function is now also used by CompileWasmToJSWrapper (unrelated to
imports).
- (Drive-by) Remove dead arguments from wasm-module-builder.js.
Bug: v8:9495
Change-Id: I23468b69d42310cb8e96da5286ce68c701188876
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459371
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70421}
The assertion states that compilation of an empty script does not add
new pages. This doesn't not necessarily hold if the existing pages are
almost full.
Bug: v8:10988
Change-Id: I71735e6736fb94e1ccde7f6430a2c4b0d48c43f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461728
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70417}
Missed this earlier when it was merged into the proposal.
f32x4 and f64x2 ceil, floor, trunc, nearestint. Also enable cctests.
Bug: v8:10507,v8:10906
Change-Id: I2de00e615cd63d81303649774db2a2ab800f6f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461451
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70415}
With this CL, fast API calls reuse the same stack slot they are
using for the {fallback} parameter. This relies on the fact that
the fast calls are non-reentrant, due to their inability to call
into JavaScript.
Bug: chromium:1052746
Change-Id: I2c56fcbe425023244a566bb39439e8e04072f316
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461729
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70409}
