Everything after UNREACHABLE is dead code, so it makes sense to remove them.
Bug: v8:9183
Change-Id: If76468a73b926d74717cc2348fd5b36d30f680c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605727
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61411}
Precise code-coverage, collecting type profile and logging function events
need feedback vectors. This cl allocates feedback vector eagerly when any of
these features are required. When the code-coverage mode changes to anything
other than best case, this scans over the entire heap and allocates feedback
vectors for the required functions.
For best case code coverage we use interrupt budget field on the feedback
cell to infer if a function has executed. We still use the invocation count
on the feedback vector if feedback vector is available.
Bug: v8:8394
Change-Id: Ia0e656aaaa024d6d893a5badafc9a42ce36e9ea3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601143
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61410}
There are two possible type:
- scriptParsed - breakpoint for any script,
- scriptWithSourceMapParsed - breakpoint for script with
sourceMappingURL.
When one of the breakpoints is set then for each matched script
we add breakpoint on call to top level function of that script.
Node: https://github.com/nodejs/node/issues/24687R=dgozman@chromium.org
Bug: chromium:887384,chromium:724793,chromium:882909
Change-Id: I9c08b2a2a5ba7006adfedd85fc92ae191517af00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1354245
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61353}
This is a reland of ad44c258d7
Patchset 2 is the original CL
Patchset 3 fixes some misuses of FixedArrayBase::length() and adds some
DCHECKS to flush out any more misuses.
Patchset 4 adds the PPC/S390 port by miladfar@ca.ibm.com.
Original change's description:
> [typedarray] Make JSTypedArray::length authoritative.
>
> This is the first step towards full huge typed array support in V8.
> Before this change, the JSTypedArray::length and the elements backing
> store length (FixedTypedArrayBase::length) were used more or less
> interchangeably to determine the number of elements in a JSTypedArray.
>
> With this change we disentangle these two lengths, and instead make
> JSTypedArray::length authoritative. For on-heap typed arrays, the
> FixedTypedArrayBase::length will remain the number of elements in the
> backing store, but for the off-heap typed arrays, this length will be
> set to 0 (matching the fact that the FixedTypedArrayBase instance does
> not contain any elements itself).
>
> This also unifies the JSTypedArray::set_/length() and length_value()
> methods to only have JSTypedArray::set_/length() which returns/takes
> size_t values. Currently this still requires the values to be in Smi
> range, but later we will extend this to allow arbitrary size_t values
> (in the safe integer range).
>
> Bug: v8:4153, v8:7881
> Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
> Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60648}
Bug: v8:4153, v8:7881, v8:9105
Change-Id: Ic38f833071a723642ebc6f82a4012dbc0878ef98
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594435
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61275}
This new function forwards to v8::Object::CreationContext but has
special handling for JSGlobalProxy objects to prevent the former from
crashing.
R=yangguo@chromium.org
Bug: chromium:952057
Change-Id: I5ade682976efd1724c13f52b468e4fb30bb9ade7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569425
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61197}
This reverts commit ad44c258d7.
Reason for revert: Missed some users: crbug.com/v8/9105
Original change's description:
> [typedarray] Make JSTypedArray::length authoritative.
>
> This is the first step towards full huge typed array support in V8.
> Before this change, the JSTypedArray::length and the elements backing
> store length (FixedTypedArrayBase::length) were used more or less
> interchangeably to determine the number of elements in a JSTypedArray.
>
> With this change we disentangle these two lengths, and instead make
> JSTypedArray::length authoritative. For on-heap typed arrays, the
> FixedTypedArrayBase::length will remain the number of elements in the
> backing store, but for the off-heap typed arrays, this length will be
> set to 0 (matching the fact that the FixedTypedArrayBase instance does
> not contain any elements itself).
>
> This also unifies the JSTypedArray::set_/length() and length_value()
> methods to only have JSTypedArray::set_/length() which returns/takes
> size_t values. Currently this still requires the values to be in Smi
> range, but later we will extend this to allow arbitrary size_t values
> (in the safe integer range).
>
> Bug: v8:4153, v8:7881
> Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
> Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60648}
TBR=jarin@chromium.org,titzer@chromium.org,hpayer@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
TBR=jarin@chromium.org, szuend@chromium.org
Bug: v8:4153, v8:7881
Change-Id: I96992bff15b4a2765ae4a557d2c37e78269c927d
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593294
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61172}
Our {Vector} template provides both {start} and {begin} methods. They
return exactly the same value. Since the {begin} method is needed for
iteration, and is also what standard containers provide, this CL
switches all uses of the {start} method to use {begin} instead.
Patchset 1 was auto-generated by using this clang AST matcher:
callExpr(
callee(
cxxMethodDecl(
hasName("start"),
ofClass(hasName("v8::internal::Vector")))
),
argumentCountIs(0))
Patchset 2 was created by running clang-format. Patchset 3 then
removes the now unused {Vector::start} method.
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
Bug: v8:9183
Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61081}
Previously we had some kind of self-healing when calling lazy accessor
pairs via InvokeApiFunction(), but we also have other paths for calling
into FunctionTemplateInfos directly, which didn't do this check. Since
we already walk the heap when installing the DebugBreakTrampoline, and
compile all uncompiled functions, we can also just forcibly instantiate
all the lazy accessor pairs at that time and not have to worry about the
break-at-entry later.
Bug: v8:178, v8:7596, v8:8834
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: I514392cf328fc8ed0b80ad19009f32e20ff850b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565890
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60813}
When clearing a DebugInfo, we need to check whether that function is
currently executing and, if so, update the on-stack BytecodeArray
pointer to refer to the original BytecodeArray. Otherwise, the original
BytecodeArray might get flushed, which can cause problems when
attempting to resume execution of the function.
Bug: v8:9067
Change-Id: Ief28a501294f5a34052e13f618fa084311eaa0b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1548573
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60774}
- Add a new ClassScope for block scopes created for classes.
- Add a VariableMap in the class scope for private name resolution,
and a separate UnresolvedList for private names that will be resolved
only using ClassScopes. These are stored in RareData and will only be
allocated when there are private name declaration or access in the
class.
Design: https://docs.google.com/document/d/1l-D70uaHzXU8QVgQZ3ACikb3FLO6LTAfQVdGDXsh5mw/edit?usp=sharing
TBR: hpayer@chromium.org
Bug: v8:8330
Bug: v8:7468
Change-Id: I78191fc075f7f195f6c56c959773c382346cce8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1488271
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60726}
Even though both are allowed in the style guide, it recommends to use
'using', as its syntax is more consistent with the rest of C++.
This CL turns all typedefs in src/debug to 'using' declarations.
R=jgruber@chromium.org
Bug: v8:8834
Change-Id: I205e14a0b230a26119e5b209a2bcec493a8815e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545901
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60698}
This is the first step towards full huge typed array support in V8.
Before this change, the JSTypedArray::length and the elements backing
store length (FixedTypedArrayBase::length) were used more or less
interchangeably to determine the number of elements in a JSTypedArray.
With this change we disentangle these two lengths, and instead make
JSTypedArray::length authoritative. For on-heap typed arrays, the
FixedTypedArrayBase::length will remain the number of elements in the
backing store, but for the off-heap typed arrays, this length will be
set to 0 (matching the fact that the FixedTypedArrayBase instance does
not contain any elements itself).
This also unifies the JSTypedArray::set_/length() and length_value()
methods to only have JSTypedArray::set_/length() which returns/takes
size_t values. Currently this still requires the values to be in Smi
range, but later we will extend this to allow arbitrary size_t values
(in the safe integer range).
Bug: v8:4153, v8:7881
Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60648}
This is a reland of 660d828790
Original change's description:
> [debug] Mark toLocaleString and TA#join builtins as side-effect free.
>
> Bug: chromium:940373
> Change-Id: If5f90ff5f873f0687c6a6a4063e0d09d6bbbd556
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533157
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#60440}
Bug: chromium:940373
Change-Id: I03fe4c06cad9848db211739170462d52ce3f7acf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538791
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#60575}
Previously when lazy source positions were enabled, source positions
were immediately collected whenever an exception was thrown for every
frame in the stack trace.
This change makes source position collection trigger only when the
source positions of a stack frame are actually accessed with the
exception of the top frame which is still eagerly collected for now.
Additionally when stack overflows occur during source position
collection, the bytecode is marked with exception in the
source_position_table field so it can be distinguished from the case
where source position collection has never been attempted (undefined)
or is not desired because the bytecode is for natives
(empty_byte_array).
Bug: v8:8510
Change-Id: If7ee68edbacc9e2adadf00fe5ec822a8dbe1c79a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520721
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60504}
Consolidates all the work into a single TFS builtin (CreateHTML)
called by all these functions. Reduces the builtin size by
about half.
Change-Id: I92b2c7889f72db4c8c79d7ef0ce0e61036ab619e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1522727
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60248}
This is the reland of https://chromium-review.googlesource.com/c/v8/v8/+/1495898
builtin_function_id corresponded to BuiltinFunctionId (a manually maintained list of 'interesting' functionsmainly used during optimization). With this change, we nuke builtin-function-id in favor of builtin-id and 8 bits is freed up in SFI.
Bug: v8:6993
Change-Id: I7e1681cc2a95864c71ce8bdda075481310607166
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506445
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60131}
Yu Yin is working for company that is willing to maintain MIPS ports
therefore I am transferring ownership to Yu Yin.
No-Presubmit: true
TBR=mstarzinger@chromium.org
NOTRY=true
Change-Id: Ibb534165a1a67ad65a58ea85f5885a70b59302be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505454
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Predrag Rudic <prudic@wavecomp.com>
Commit-Queue: Predrag Rudic <prudic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#60054}
This reverts commit f8a676707d.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/25576
I don't think I've seen MSAN being flaky. Chances are that the change to SFI's object layout indeed left some field uninitialized.
Original change's description:
> Remove builtin-function-id in SFI
>
> builtin_function_id corresponded to BuiltinFunctionId (a manually maintained list of 'interesting' functionsmainly used during optimization). With this change, we nuke builtin-function-id in favor of builtin-id and 8 bits is freed up in SFI.
>
> Bug: v8:6993
> Change-Id: Iee9b539475bc6531c9aa65b1904d1402a9ef30db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495898
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60017}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,duongn@microsoft.com
Change-Id: Ic3964ce182ddbd7ef529ddb8b78b9bdfb1be7887
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499500
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60018}
builtin_function_id corresponded to BuiltinFunctionId (a manually maintained list of 'interesting' functionsmainly used during optimization). With this change, we nuke builtin-function-id in favor of builtin-id and 8 bits is freed up in SFI.
Bug: v8:6993
Change-Id: Iee9b539475bc6531c9aa65b1904d1402a9ef30db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495898
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60017}
... by skipping over them. Such variables appear in the case of direct
namespace exports and default exports. (Actually, the name used for
default exports used to be "*default*" which is not recognized as
synthetic, so I'm renaming it here to ".default").
Bug: chromium:932111
Change-Id: I0554dae9614334fdc02e78606f2db47e92196429
Reviewed-on: https://chromium-review.googlesource.com/c/1494010
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60012}
If we make use of this in the generic Array.prototype.filter case
we get a performance boost of over 60%.
Bug: v8:8213, chromium:920187
Change-Id: Ia116a852f355a9f037850aee86db7284f0023929
Reviewed-on: https://chromium-review.googlesource.com/c/1484297
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59979}
This CL moves the following builtins from CSA to Torque:
TypedArray.prototype.forEach
TypedArray.prototype.reduce
TypedArray.prototype.reduceRight
A space-saving decision was made in the design -- instead of emitting
versions of the central loop for each ElementsKind, a function
pointer which knows how to read from the appropriate TypedArray
ElementsKind is constructed at the outset, and passed into the
loop. This enormously reduces codesize for the TypedArray builtins.
We'll have to see if the overhead of the builtin call affects
performance too adversely.
BUG: v8:8906
Change-Id: I808cd70f58ddbde18f85e5b2a9be0b883a3f6647
Reviewed-on: https://chromium-review.googlesource.com/c/1484292
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59970}
This will allow the devtools UI to display private fields on the scope
panel.
Instead of extending GetInternalProperties, we expose a separate
GetPrivateFields method on the debug interface. This allows us to do
better type checking, for example, we can directly cast to a
v8::Private as this can only contain private fields.
This also allows us to have better constraints on the input type --
v8::Object, as opposed to a v8::Value.
The KeyAccumulator is extended to collect private names for the
PRIVATE_NAMES_ONLY PropertyFilter.
Bug: v8:8773
Change-Id: Id47c551186c59dae9a06721074ef78144f25892f
Reviewed-on: https://chromium-review.googlesource.com/c/1475664
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59920}
Moved CoverageMode and TypeProfileMode enums to interface-types.h
to save one include in isolate.h. This reduces the expanded lines of code
count by ~45k.
Bug: v8:8834
R=yangguo@chromium.org
Change-Id: I399fe8cf66b1aec79bcb5831afd46a74e358244d
Reviewed-on: https://chromium-review.googlesource.com/c/1489072
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59886}
This removes ast.h as include from about ~500 includers of the latter.
Bug: v8:8834
Change-Id: I294026d4bb29b878820d43c117b04a9645a457ae
Reviewed-on: https://chromium-review.googlesource.com/c/1485835
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59822}
This fixes ~15 debug/inspector tests that were failing when
v8_enable_lazy_source_positions = true.
Bug: v8:8510
Change-Id: Ica02aa2ea84549b5cddd82b5b98835829f7b0f1b
Reviewed-on: https://chromium-review.googlesource.com/c/1477280
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59695}
These are no longer needed now that JS builtins have been fully
removed.
The internal match usage in assert.js has been replaced by a custom
miniparser. The internal replace use in various string builtins was
replaced by manual global string replacement in a runtime function.
Bug: v8:8842,v8:7624
Change-Id: Ieb49c694662a13e84fd9fd2fe5d0412b8e0574da
Reviewed-on: https://chromium-review.googlesource.com/c/1473030
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59689}
This takes heap-inl.h out of the "Giant Include Cluster".
Naturally, that means adding a bunch of explicit includes
in a bunch of places that relied on transitively including
them before.
As of this patch, no header file outside src/heap/ includes
heap-inl.h.
Bug: v8:8562,v8:8499
Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4
Reviewed-on: https://chromium-review.googlesource.com/c/1459659
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59617}
If enable_omit_source_positions is true (defaults to false), source
position tables are not generated when compiling bytecode. They will
then be regenerated when exceptions are thrown.
This adds a new function Compiler::CollectSourcePositions which given a
SharedFunctionInfo with bytecode but no source position table re-parses
and regenerates the bytecode but this time with source positions
collection enabled. Note this will reparse all inner functions that
have previously been compiled since the preparse data is no longer
available.
With the flag enabled there still 18 test failures mostly related to
debugging.
v8: 8510
Change-Id: I46dff9818d8a89c901ba8ae8df94dcaca83aa658
Reviewed-on: https://chromium-review.googlesource.com/c/1385165
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59595}
Class member initializer functions do not support lazy compilation, so
change FunctionLiteral::AllowsLazyCompilation to return false for them.
Change-Id: I38434f3a7e8c88af3f407cf19308fc3862ec4403
Reviewed-on: https://chromium-review.googlesource.com/c/1470103
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59588}
This CL introduces TurboAssembler::LoadTaggedPointerField() and
TurboAssembler::LoadAnyTaggedField(), which respectively loads a field
containing a HeapObject, or any tagged value, and decompresses it if necessary.
Bug: v8:7703
Change-Id: I71ace74d7433a3a78d56bdcef6d2ec041df630e4
Reviewed-on: https://chromium-review.googlesource.com/c/1456098
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59501}
This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
Original change's description:
> [builtins] [turbofan] Refactor Float64Pow to use single implementation
>
> Remove platform-specific Float64Pow implementations and utils Pow in
> favor of a base::ieee754::pow implementation.
>
> This unifies the implementation of pow for the compiler, wasm, and
> runtime.
>
> Bug: v8:5848, v8:5086
> Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
> Reviewed-on: https://chromium-review.googlesource.com/c/1403018
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59229}
Bug: v8:5848, v8:5086
Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1447854
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59411}
"this" is a very common expression. By using a single ThisExpression object
we can both avoid allocating many unnecessary VariableProxies and specialize
the resolution of this since we know where it's declared up-front. This also
avoids having to special-case "this" reference handling in the paths that would
behave differently for "this" than for regular references; e.g., with-scopes.
The tricky pieces are due to DebugEvaluate and this/super() used as default
parameters of arrow functions. In the former case we replace the WITH_SCOPE
with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still
rely on regular dynamic variable lookup. Arrow functions are dealt with by
marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression
ends up being an arrow function, we force context allocate on the outer scope
(and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the
arrow function can expose "this").
The CL also removes the now unused ThisFunction AST node.
Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef
Reviewed-on: https://chromium-review.googlesource.com/c/1448313
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59393}
movXXXp are replaced with respective movXXXq.
Drive-by cleanup: unified the way we generate movq with other mov instructions.
Bug: v8:8621, v8:8562
Change-Id: I5c65dccf4e460cad5c3cee3dfabfd6ce39abc244
Reviewed-on: https://chromium-review.googlesource.com/c/1446096
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59243}
This reverts commit 595aafeb21.
Reason for revert:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8922824501209195616/+/steps/Mozilla/0/logs/15.8.2.13/0
Original change's description:
> [builtins] [turbofan] Refactor Float64Pow to use single implementation
>
> Remove platform-specific Float64Pow implementations and utils Pow in
> favor of a base::ieee754::pow implementation.
>
> This unifies the implementation of pow for the compiler, wasm, and
> runtime.
>
> Bug: v8:5848, v8:5086
> Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
> Reviewed-on: https://chromium-review.googlesource.com/c/1403018
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59229}
TBR=yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,clemensh@chromium.org,me@gus.host
Change-Id: I266df4b8350cfcebcea8f6063ad75ad962381105
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5848, v8:5086
Reviewed-on: https://chromium-review.googlesource.com/c/1447715
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59232}
Remove platform-specific Float64Pow implementations and utils Pow in
favor of a base::ieee754::pow implementation.
This unifies the implementation of pow for the compiler, wasm, and
runtime.
Bug: v8:5848, v8:5086
Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
Reviewed-on: https://chromium-review.googlesource.com/c/1403018
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59229}
Inferring the language mode involves iterating the stack to find the
closure. This is an expensive operation and should be done only when
required. This cl changes the implementation to infer the language
mode only when we can't defer it any further. Currently, we infer the
language mode when throwing an exception or when passing this
information to PropertyCallbackArguments.
This cl also changes the language mode parameter to SetProperty
related methods to Maybe<ShouldThrow>. We only use the language mode to
decide if we need to throw and using ShouldThrow instead of language
mode simplifies the code by avoiding conversions from Maybe<ShouldThrow>
to Maybe<LanguageMode> and vice-versa.
Bug: v8:8580, chromium:923820, chromium:925289
Change-Id: I72497497f62fe0d86fcecd57b06b3183b7531f7b
Reviewed-on: https://chromium-review.googlesource.com/c/1425912
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59094}
This is a reland of 0896599f6f with a fix for
failing layout test.
Original change's description:
> Change SetProperty/SetSuperProperty to infer language mode when possible
>
> In most cases, the language mode can be inferred from the closure and
> the context. Computing the language mode instead of passing it around
> simplifies the ICs and will make it possible to go towards lazily
> allocating feedback vectors. Currently ICs obtain the language mode from
> the feedback vectors and with lazy feedback allocation we may not always
> have feedback vectors. Since computing language mode is a bit expensive
> we want to defer it as far as possible.
>
> In Array builtins and other builtins like Reflect.Set we need to force a
> language mode when setting the properties. To support these cases the
> SetProperty methods allow the language mode to be overridden when needed.
>
> This is a first cl in a series of cls, that will defer the language mode
> computation further and remove language mode where it is not needed.
>
> BUG: v8:8580
> Change-Id: I9c2396e3bcfe77c3c9d6760c46d86954d54744b9
> Reviewed-on: https://chromium-review.googlesource.com/c/1409426
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58893}
TBR: ahaas@chromium.org
Change-Id: Id5d81eae91b55638dbc72168f0e5203e684869fb
Reviewed-on: https://chromium-review.googlesource.com/c/1421077
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59075}
