We also introduce a subclass of AbstractBytecodeArray to allow access
to the off-heap copy of bytecode array from the bytecode iterator.
Note that not all bytecode iterators have been converted to iterate
the off-heap copy; in particular, bytecode analysis still iterates
the on-heap bytecode array.
Bug: v8:7790
Change-Id: Icc1b0adb5f63d7cfe94286311f64f209067bbfd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672931
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62403}
v8memory.h does not have V8 specific definitions, and having it in base
makes it clear that every component may include the file. It also
ensures that including it does not create spurious dependencies on
v8_base.
Change-Id: I565f63b25f33a9ada19d7b2ac5990863ab17f4a7
Bug: v8:9183, v8:8855
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657923
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62309}
Makes the order of the generated calls to the Runtime function
DefineAccessorPropertyUnchecked fixed regardless of hashseed so that
recompilation for lazy source positions always generates the same
result.
Moves AccessorTable from src/ast/ast.h to bytecode-generator.cc since
that's the only place that uses it.
Bug: v8:9383, v8:8510
Change-Id: I89e0aad1683a793714bfb48eca1b00abe20cad0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669689
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62303}
Introduce SourceTextModule as a subclass of Module. Move all the
JavaScript-module-specific code down from Module to
SourceTextModule, with all code applicable to other future
module types remaining in Module.
With this change, Module is roughly equivalent to the spec's
Abstract Module Record and SourceTextModule is roughly equivalent
to Source Text Module Record.
Bug: v8:9292
Change-Id: I6e9cd3ece9d0c1da57e52f8af8ed5848d87dd22d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1633154
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62296}
This disallows using CSA macros from Torque that have a Node* return
type instead of TNode<>. By enforcing CSA types at the boundary between
CSA and Torque, we can ensure that the Torque types and the CSA types
match.
As a drive-by, this CL adds a bit more of CSA typing where it made sense.
Bug: v8:7793, v8:6949
Change-Id: I12ea0337c628105ea3c420be747ae50d3a172547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660481
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62293}
This patch implements the access of private methods:
- When building property loads, check whether it requires
a brand check. If so, build the brand check and load the
property (the method) from the context instead.
- Throw type errors when there is an attempted write to private
methods.
Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
Bug: v8:8330
Change-Id: Ic917d2a0030196c1940b0c0ba65a340af736c769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1610383
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62292}
This is to allow instantiating things like bytecode array iterator for
accessing both on-heap and off-heap bytecode arrays.
Bug: v8:7790
Change-Id: I8dbd0884f79923d69dbc8b168d3a4a200eab14b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1640199
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62266}
This patch adds a new assign type `PRIVATE_METHOD`. We now use this
for private method references in the form `obj.#key` when `#key`
resolves to a private method.
To obtain the type of the key variables after scope analysis, this
patch add a bit to Variable to recognize private method variables
whose load requires a brand check.
Also renamed `PropertyExpressionWithPrivateFieldKey` in ExpressionType
to `PrivateReference` and added `PRIVATE_CALL` to `CallType` - we'll
use the new types later when we implement private methods, which
require special brand checking semantics to load methods directly
from the context instead of from the object in order to save memory.
Bug: v8:8330
Change-Id: Idc1dcd4d514c1b3f8a31c99e49e34249449f0677
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1642772
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62255}
This in in preparation for generic (off-heap/on-heap) bytecode
array accessor.
Bug: v8:7790
Change-Id: Ib419831ba1db95ab938179723ef5f130f01ae0d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635895
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62222}
The CloneObject bytecode was only able to handle objects, null and
undefined, and explicit bytecode had to be generated to perform the
ToObject outside the bytecode (unlike the other IC bytecodes that
just perform the ToObject implicitly). That means the simplest possible
object cloning would also generate a sequence of 5 bytecodes (at least):
```
Mov <register>, a0
JumpIfNull @1
JumpIfUndefined @1
ToObject <register>
1: CloneObject <register>
```
That is quite wasteful and unnecessary, since the core logic in the
runtime already does the ToObject properly anyways. This change
refactors the CloneObjectIC slightly to behave more like the other ICs
and do the ToObject implicitly when necessary.
Bug: v8:7611, v8:9114, v8:9183, v8:9343
Change-Id: I11973e90bf875f154a5a7739287bee17041e4a7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649554
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62064}
As per the new specs, when the exception is thrown by iterator's return method
while doing iterator close because it is not callable, the exception is
suppressed in the same way as if the return method is called and threw an exception.
https://github.com/tc39/ecma262/issues/1398
Bug: v8:9056
Change-Id: I21abd5fdd01d3a957c3c16d9d3aaab9091e43142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648256
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#62035}
Fixes LookupNameOfBytecodeHandler so it actually returns non-nullptr
values with embedded builtins enabled. Also now correctly handles wide
and extra-wide bytecodes and always works regardless of whether
ENABLE_DISASSEMBLER is set.
Bug: v8:9215
Change-Id: I787134f2145d02daaf5b50ecb6c174dfc129a4fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635890
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61929}
Change-Id: I94ad60d487e64fa72cd3123c85a1b8460ea1007b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630671
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61881}
Introduce a single point to emit CodeCreateEvents for all builtins in
Isolate::Init. At this location, we cover both the case of builtin generation
(e.g. in mksnapshot) and deserialized builtins (in standard builds),
whereas previously we only emitted events post-builtin-generation.
In order to preserve behavior for bytecode handler events, pack the bytecode
and operand scale into our existing builtin metadata table.
Drive-by: Update way-out-of-date comment in the static initializer
check.
Bug: v8:8674
Change-Id: Iced8f73568e920846cde6f7b0a9c1e61844258ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627337
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61782}
This CL was generated by an automatic clang AST rewriter using this
matcher expression:
callExpr(
callee(
cxxMethodDecl(
hasName("operator->"),
ofClass(isSameOrDerivedFrom("v8::internal::Object"))
)
),
argumentCountIs(1)
)
The "->" at the expression location was then rewritten to ".".
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org
Bug: v8:9183, v8:3770
No-Try: true
No-Tree-Checks: true
Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61764}
This CL also removes the corresponding intrinsic lowering of
IsTypedArray in TurboFan and Ignition.
Drive-by: Remove unused ArrayBufferViewWasDetached runtime function.
Bug: v8:9183
Change-Id: I2767b22fbdfb679cba30b9fbc555c8d41c7f4345
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617930
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61677}
This reverts commit 5f28539599.
Reason for revert: presubmit failure
Original change's description:
> Move logging and diagnostics related source files
>
> This also introduces a COMMON_OWNERS file, which is derived from the
> current top-level OWNERS file. It is to be used for parts of the
> codebase that is not sensitive to domain-specific expertise.
>
> NOPRESUBMIT=true
> TBR=verwaest@chromium.org
>
> Bug: v8:9247
> Change-Id: I34a5eaa7cb1509a80d15094a2aceedd62665b17c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613987
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61600}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org
Change-Id: I3827c3af4fd63b18aa48c49617f318a01746e813
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617247
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61601}
This also introduces a COMMON_OWNERS file, which is derived from the
current top-level OWNERS file. It is to be used for parts of the
codebase that is not sensitive to domain-specific expertise.
NOPRESUBMIT=true
TBR=verwaest@chromium.org
Bug: v8:9247
Change-Id: I34a5eaa7cb1509a80d15094a2aceedd62665b17c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613987
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61600}
Prior to this CL, call counts at function scope were taken from the
FeedbackVector::invocation_count field. This had two major drawbacks:
1. for generator functions, these count the number of resumptions
instead of the number of calls; and 2. the invocation count is not
maintained in optimized code.
The solution implemented here is to add a dedicated call counter at
function scope which is incremented exactly once each time the
function is called.
A minor complication is that our coverage output format expects
function-scope counts in the dedicated CoverageFunction object, and
not as a CoverageBlock. Thus function-scope block counts are initially
marked with magic positions, and later recognized and rewritten during
processing.
This CL thus fixes reported generator function call counts and enables
optimizations in block coverage modes (more to come in a follow-up).
Drive-by: Don't report functions with empty source ranges.
Bug: v8:6000,v8:9148,v8:9212
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61574}
Added null check when printing the brand with --print-ast.
Bug: chromium:961507, chromium:961508
Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
> context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
> constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}
Change-Id: I3bf465f70c27914c9ec19f3f59ae018b28c9a866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605521
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61459}
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}
This reverts commit b9191bd355.
Reason for revert: Clusterfuzz bugs
BUG=chromium:961507,chromium:961508
Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
> context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
> constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}
TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8330
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61406}
Per 262, yield* for async generators is supposed to Await the input value.
#sec-generator-function-definitions-runtime-semantics-evaluation
Section 14.4.13, yield *, 7.c.iii.1
Bug: v8:9051
Change-Id: Ie1e829309fe78683a9ff0adf816208c2bf0bb524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1600508
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61390}
This patch implements the declarations of private methods, the access
of private methods would be left to a future patch.
When a private methods declaration is encountered, we now:
- Create a brand symbol during class evaluation and store it in the
context.
- Create the closures for the private methods
- Load the brand from the context and store it in the instance in the
constructor.
Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
Bug: v8:8330
Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61387}
This adds a new %_CopyDataProperties intrinsic, that reuses most of the
existing machinery that we already have in place for Object.assign() and
computed property names in object literals. This speeds up the general
case for object spread (where the spread is not the first item in an
object literal) and brings it on par with Object.assign() at least - in
most cases it's significantly faster than Object.assign().
In the test case [1] referenced from the bug, the performance goes from
objectSpreadLast: 3624 ms.
objectAssignLast: 1938 ms.
to
objectSpreadLast: 646 ms.
objectAssignLast: 1944 ms.
which corresponds to a **5-6x performance boost**, making object spread
faster than Object.assign() in general.
Drive-by-fix: This refactors the Object.assign() fast-path in a way that
it can be reused appropriately for object spread, and adds another new
builtin SetDataProperties, which does the core of the Object.assign()
work. We can teach TurboFan to inline Object.assign() based on the new
SetDataProperties builtin at some later point to further optimize
Object.assign().
[1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0
Bug: v8:9167
Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61100}
When collecting JS block coverage, we track block execution counts on
so-called CoverageInfo objects. Generated bytecode and native code
contains inlined snippets of code to increment the appropriate
counters.
These used to be implemented as calls to the IncBlockCounter runtime
function. Each call incurred the entire CEntry overhead.
This CL reduces that overhead by moving logic over into a new
IncBlockCounter TFS builtin. The builtin is called directly from
bytecode, and lowered to the same builtin call for optimized code.
Drive-by: Tweak CoverageInfo layout to generate faster code.
Tbr: jarin@chromium.org
Bug: v8:9149, v8:6000
Change-Id: I2d7cb0db649edf7c56b5ef5a4683d27b1c34605c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571420
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60981}
Avoids allocating a frame for the fast-path in IncHandler by marking some calling
branches as Deferred. Also avoid loading feedback slot and vector until it's needed
to reduce live range.
This reduces the time needed for a tight loop in Ignition (e.g.,
while (i < 1000000000) ++i;) from 15.5s to 12.8s.
BUG=v8:9133
Change-Id: I0a62efdaefca7f3024b3ae05c61631a63cb01390
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570005
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60893}
This is particularly useful to fuzzers that seek to provoke
optimization.
Bug: v8:9119
Change-Id: I729f72a0e22686fbd56793875175c230e0230823
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564196
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60794}
This is a reland of Ie3ac389e1c082d1671efd4d74abc076ce943301b with a fix
for MSAN failures.
Interrupt budget was store in bytecode array and used to be shared
across all contexts. With lazy feedback allocation, using context
independent interrupt budget might lead to performance cliffs when
we have closures that do not share the same feedback (for ex: across
contexts). This would be a problem even earlier but it could be
more pronounced with feedback vector allocation, since the budgets
for optimization is much higher (144x) than the budget for feedback
allocation.
Bug: chromium:948835, v8:8394
Change-Id: I74f998c30e27caf3bd34510f4d7f57b65e6c7f0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561072
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60750}
This reverts commit f39944853f.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/26128
Original change's description:
> [interpreter] Move interrupt budget from BytecodeArray to FeedbackCell
>
> Interrupt budget was store in bytecode array and used to be shared
> across all contexts. With lazy feedback allocation, using context
> independent interrupt budget might lead to performance cliffs when
> we have closures that do not share the same feedback (for ex: across
> contexts). This would be a problem even earlier but it could be
> more pronounced with feedback vector allocation, since the budgets
> for optimization is much higher (144x) than the budget for feedback
> allocation.
>
> Bug: chromium:948835, v8:8394
> Change-Id: Ie3ac389e1c082d1671efd4d74abc076ce943301b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558088
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60734}
TBR=jarin@chromium.org,mlippautz@chromium.org,mythria@chromium.org,jgruber@chromium.org,bmeurer@chromium.org
Change-Id: Icbec4d28d6ac258827e222461cff51f2a2f42472
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:948835, v8:8394
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560990
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60735}
Interrupt budget was store in bytecode array and used to be shared
across all contexts. With lazy feedback allocation, using context
independent interrupt budget might lead to performance cliffs when
we have closures that do not share the same feedback (for ex: across
contexts). This would be a problem even earlier but it could be
more pronounced with feedback vector allocation, since the budgets
for optimization is much higher (144x) than the budget for feedback
allocation.
Bug: chromium:948835, v8:8394
Change-Id: Ie3ac389e1c082d1671efd4d74abc076ce943301b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558088
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60734}
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 interpreter code to 'using' declarations.
R=leszeks@chromium.org
Bug: v8:8834
Change-Id: Ide1e8a35a56a840b36b3ceab1307df1bcab94acd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545900
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60609}
The native flag is a left-over from self-hosted JavaScript. Currently
only the empty function and empty script are marked native.
This CL removes the native flag from the ParseInfo,
UnoptimizedCompilationInfo and its handling in the bytecode generator.
R=leszeks@chromium.org
Bug: v8:8834,v8:9043
Change-Id: I60726e28ce83cc84249e9c49bdc88d81f0a695c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545079
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60606}
With lazy feedback allocation we load the interrupt budget from the
ClosureFeedbackCellArray instead of the bytecode array. The factory method
that constructs the ClosureFeedbackCellArray ensures we have a field for
interrupt budget. So, it is safe to omit bounds check here. Including the
bounds check increases the size of all jump bytecode handlers by around
~120 bytes. This translates to ~9-10KB of the native code size on Android.
Bug: chromium:948835
Change-Id: I8e10b3f630097728ae9e520bfb0d85dfc0f806ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550403
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60603}
- Use IsInRange
- Convert scale to index using >>1 which works for 1, 2, 4
- Use mask to check Reads/Writes accumulator
Change-Id: Iaeb2236a2d179dc70b62fa599c08984800170336
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541039
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60595}
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}
Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.
Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
We want to allocate feedback vectors lazily in lite mode. To do that,
we should create closures with the correct feedback cell. This cl
allocates feedback cell arrays to hold these feedback cells in lite mode.
This cl also modifies the compile lazy to builtin to expect these arrays
in the feedback cell.
Drive-by fix: InterpreterEntryTrampoline no longer has argument count in
a register. So updated comments and removed unnecessary push/pop of this
register.
Bug: v8:8394
Change-Id: I10d8ca67cebce61a284f0c80b200e1f0c24577a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511274
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60189}
This is a pre-work for allocating feedback vectors lazily. Feedback cells
are required to share the feedback vectors across the different closures
of the same function. Currently, they are held in the CreateClosureSlot
in the feedback vector. With lazy feedback vector allocation, we may not
have a feedback vector. However, we still need a place to store the
feedback cells, so if feedback vector is allocated in future it can still
be shared across closures.
Here is the detailed design doc:
https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit
BUG=v8:8394
Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60147}
The {id_} stored in {ThreadId} should not be atomic. Only getting a new
id for the current thread needs to be atomic. If any user of {ThreadId}
needs atomicity, that user should wrap {ThreadId} in a {std::atomic}
instead.
Drive-by: Remove {Equals} method, use {operator==} instead.
Drive-by: Move static methods after member methods.
R=ishell@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Bug: v8:8834
Change-Id: Id0470eb2fa907948843ac1153e2dc5dcd9a8fbc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1494006
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60146}
The original was reverted for breaking webkit layout tests:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
It also caused the following clusterfuzz failures:
chromium:935832
This was a correctness bug due to not properly handling the case of arrays with prototypes other
than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
both in access-assembler and in Turbofan.
chromium:935932
This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
debug builds but in release could show up in different places. This is the bug that caused the
webkit layout test failure that led to the revert.
Both bugs are fixed by in CL, and tests are added for those cases.
Bug: v8:8733, chromium:935932, chromium:935832
Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
Reviewed-on: https://chromium-review.googlesource.com/c/1493132
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59958}
Rather than manually tracking basic blocks in the bytecode array builder,
use the existing dead code elimination to generate an implicit return iff
the block ending the bytecode is not dead by the time all statements have
been visited.
Change-Id: I9520486a523ec4e01bc203e9a847eb1f57b130b6
Reviewed-on: https://chromium-review.googlesource.com/c/1494756
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59951}
This is a reland of 35269f77f8
Switches on an expression that unconditionally throws would have all their
case statements dead, causing a DCHECK error in the SwitchBuilder. This
fixes up the DCHECK to allow dead labels.
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org
Bug: chromium:934166
Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
Reviewed-on: https://chromium-review.googlesource.com/c/1494535
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59948}
This reverts commit 35269f77f8.
Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org,leszeks@chromium.org
Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:934166
Reviewed-on: https://chromium-review.googlesource.com/c/1494534
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59947}
BytecodeLabels for forward jumps may create a dead basic block if their
corresponding jump was elided (due to it dead code elimination). We can
avoid generating such dead basic blocks by skipping the label bind when
no corresponding jump has been observed. This works because all jumps
except JumpLoop are forward jumps, so we only have to special case one
Bind for loop headers to bind unconditionally.
Since Binds are now conditional on a jump existing, we can no longer rely
on using Bind to get the current offset (e.g. at the beginning of a try
block). Instead, we now expose the current offset in the bytecode array
writer. Conveniently, this means that we can be a bit smarter about basic
blocks around these statements.
As a drive-by, remove the unused Bind(target,label) function.
Bug: chromium:934166
Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
Reviewed-on: https://chromium-review.googlesource.com/c/1488763
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59942}
This reverts commit 32fc0acfef.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
layout test breakage:
https://test-results.appspot.com/data/layout_results/V8-Blink_Linux_64/30270/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html
There is a dead node arriving in representation selection, which might indicate that the problem is not in this CL, but that this CL stirs up the node soup in such a way that dead code elimination gets confused.
Original change's description:
> Optimize `in` operator
>
> This change implements optimizations for the `in` operator for packed array
> elements and object properties. It adds a new feedback slot kind and an IC
> path similar to KeyedLoadIC for handling the lookups. TurboFan uses the
> feedback to optimize based on the maps and keys.
>
> For more details see:
> https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig
>
> This can provide 10x performance improvements of on loops of the form:
>
> for (let i = 0; i < ary.length; ++i) {
> if (i in ary) {
> ...
> }
> }
>
>
> Bug: v8:8733
> Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8
> Reviewed-on: https://chromium-review.googlesource.com/c/1432598
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Matt Gardner <magardn@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#59843}
TBR=ulan@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org,magardn@microsoft.com
Change-Id: Ib2db974e5bed4c4a2b6b450f796bdc4b0b8fd562
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8733
Reviewed-on: https://chromium-review.googlesource.com/c/1488761
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59857}
This change implements optimizations for the `in` operator for packed array
elements and object properties. It adds a new feedback slot kind and an IC
path similar to KeyedLoadIC for handling the lookups. TurboFan uses the
feedback to optimize based on the maps and keys.
For more details see:
https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig
This can provide 10x performance improvements of on loops of the form:
for (let i = 0; i < ary.length; ++i) {
if (i in ary) {
...
}
}
Bug: v8:8733
Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8
Reviewed-on: https://chromium-review.googlesource.com/c/1432598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59843}
Template objects should be cached after they are first created and reused on
subsiquent calls to tag functions. Currently these cached objects are stored
on the feedback vector, which has appropriate lifetime, however with bytecode
flushing the feedback vector could be cleared when the bytecode is flushed,
causing the template object to be dropped.
In order to retain the cached template objects in the face of bytecode flushing,
this CL adds a weakmap for each native context that is (weakly) keyed by
shared function info, and holds a linked list of cached template objects
associated with that shared function info, indexed by feedback vector slot id.
Misses will check this weakmap, and if no entry is found, a new template object
is created and added into this weakmap alongside the feedback vector.
BUG=v8:8799,v8:8799,v8:8395
Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17
Reviewed-on: https://chromium-review.googlesource.com/c/1477746
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59818}
This cl moves the valid feeback vector checks to the builtins and uses
fast paths runtime when possible even whithout a valid feedback vector.
For LoadNamedProperty it calls LoadIC_Uninitialized which does not need
any type feedback and for LoadKeyedProperty it follows the megamorphic path
but doesnot use the stub cache.
Bug: v8:8293
Change-Id: I6ef9653e3f43c15cb882cbf82c3c2f63fb705a81
Reviewed-on: https://chromium-review.googlesource.com/c/1475393
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59755}
Updates CloneIC builtin to take the CloneIC_slow path when there is no
feedback vector. Also fixes the CloneIC_Slow to handle proxies correctly.
StoreInArrayLiteralIC doesn't change the behaviour but just makes it
consistent with other ICs.
Bug: v8:8293
Change-Id: Ib824b3ef06db1595ce06f04669857bb957cbe072
Reviewed-on: https://chromium-review.googlesource.com/c/1475750
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59682}
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}
The megamorphic case in the KeyedStoreIC doesn't use/update any feedback.
We could use this path to fast path some of the keyed stores instead of
misssing to the runtime when the feedback vector is not available. This
cl, moves the check for feedback vector from the bytecode handler to the
KeyedStoreIC and calls the KeyedStoreIC_Megamorphic builtin when there is
no valid feedback vector. This will help improve the performance of no
feedback/jitless case.
Bug: v8:8293
Change-Id: I71c128b355d47ac20e50fc836f4bc2cf0aab1154
Reviewed-on: https://chromium-review.googlesource.com/c/1460946
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59590}
The uninitialized case in the StoreIC doesn't use any feedback.
We could use this path to fast path some of the named stores instead of
missing to the runtime when the feedback vector is not available.
Bug: v8:8293
Change-Id: Ib3c4f843b24a377708f8db18fae10983e5633484
Reviewed-on: https://chromium-review.googlesource.com/c/1463781
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59580}
For macros expanding to function definitions, I removed the spurious ; after
macro invocations. For macros expandign to function declarations, I made the ;
required and consistently inserted it.
No behavior change.
Bug: chromium:926235
Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549
Reviewed-on: https://chromium-review.googlesource.com/c/1467545
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59558}
"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}
The most common use of {SaveContext} is to allocate this object, then
immediately set the context of the isolate to another Context. Thus
introduce a second class called "SaveAndSwitchContext" which implements
exactly that.
R=mstarzinger@chromium.org
Bug: v8:8562
Change-Id: I2fca1eadd909a7afe035316ded934624273f2e21
Reviewed-on: https://chromium-review.googlesource.com/c/1448319
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59323}
SetProperty now infers the language mode from the closure and the context
So we no longer have to pass around the language mode. Cleanup by
removing the parameter where it is no longer needed.
Bug: v8:8580
Change-Id: I89452b5a762eb48a911f158d22c7bfa9e3bb1be4
Reviewed-on: https://chromium-review.googlesource.com/c/1421840
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59089}
Declare Variables with a name and position, rather than by passing
through a VariableProxy. This allows us to not create dummy proxies
for things like function declarations, and allows us to consider those
declarations unused.
As a side-effect, we also have to check if a variable is unused in the
bytecode generator (as it will no longer be allocated), and we end up
skip generating code/SFIs for dead variables/functions.
Change-Id: I4c2c872473f23e124f9456b4b92f87159658f8e0
Reviewed-on: https://chromium-review.googlesource.com/c/1414916
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59088}
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}
V8 implements "delete this" as "LdaTrue", but an error needs to be thrown
if done in a constructor before calling super. ThrowIfHole checks the
accumulator, so we need to load 'this' into the accumulator. The check is
inserted by the load since it has HoleCheckMode::kRequired
Bug: https://bugs.chromium.org/p/v8/issues/detail?id=6711
Change-Id: I9f2ce4439505cec4327d88d1195898782edea721
Reviewed-on: https://chromium-review.googlesource.com/c/1419084
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59007}
Some includes in log.h were only needed by log.cc so move them there.
Some were not needed at all, so remove them completely.
Drive-by cleanup FunctionEvent(), which was never called without args
for the last parameters which had default values.
Change-Id: Id8b0c634c4d39d3c278ab3d932ed7af4142fd9c9
Reviewed-on: https://chromium-review.googlesource.com/c/1425914
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59003}
The decision as to whether to optimize an IIFE as oneshot depends on
whether it's outer scope is the script scope. During lazy compile, we
might have discarded scopes which don't need a context between the IIFE
and the script scope, which means we might treat an IIFE as oneshot,
even though initial eager compile treated it as non-oneshot. Both
bytecode flushing and lazy source positions rely on us generating the
same bytecode during lazy compile as eager compile, so we move the
decision into the parser where it happens once and is then stored in
the SFI for any future lazy compiles.
BUG=v8:8395,v8:8510
Change-Id: I88f1e74ad95d47a2636c393ceb1318d7d610055d
Reviewed-on: https://chromium-review.googlesource.com/c/1421841
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58996}
Everything was including log.h through heap-inl.h, so remove that
include by moving the one user into heap.cc, and then fix all the
include errors.
This reduces the log.h include ball from ~550 to ~100.
Change-Id: I6d09bc2f365b48645fcfdc695a68ea12539a745d
Reviewed-on: https://chromium-review.googlesource.com/c/1424198
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58981}
- Use unique ptrs for owned objects
- Remove friendship with CpuProfiler and replace with public API
- Remove unused method LogFailure()
- Remove StopProfiler() which was only used by LogFailure() (removed)
and one test, which can use StopProfilerThread() instead
- Remove 'paused' state which was only used by the above
- Remove 'engage' state. There is no reason we need this as along as
users keep track of Engage/Disengage calls
Drive-by cleanup:
- Remove import of log.h from profile-generator.h
- Remove unnecessary includes of log.h
Change-Id: Ifc4ca156bef038c40953f8361ffea17788e3a59b
Reviewed-on: https://chromium-review.googlesource.com/c/1424338
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58957}
That makes the declaration in sync with how dynamic references are resolved,
avoiding duplicate variable creation in the likely case that the variable is
also referenced within the eval.
Bug: v8:5112, v8:5135, v8:8693
Change-Id: I0c55495f573fe8b5076b1627c139ff72d1adda74
Also-by: leszeks@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/1408890
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58850}
Storing a VariableProxy in declarations means that a declaration and
initialisation assignment are tightly coupled to use the same var. In
particular, this means that Var declarations in with scopes have to
clone the VariableProxy to split the declaration and initializer LHS
lookup.
This patch changes declarations to point directly to the Variable, not
the VariableProxy. This will allow future refactoring to decouple
declarations and initialisations.
Change-Id: I0baa77bfd12fe175f9521d292740d7d712cffd37
Reviewed-on: https://chromium-review.googlesource.com/c/1406683
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58843}
This removes the iteration protocol from the parser entirely, and opens
up future possibilities for more bytecodes implementing the various
functions of the protocol.
Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb
Reviewed-on: https://chromium-review.googlesource.com/c/1403125
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58795}
For desrtucturing assignments from null/undefined, we throw an error
that references the destructuring object literal's property name, e.g.
for
var { x } = null;
we report that we cannot destructure 'x' from null.
Rather than calculating this property during bytecode generation (and
including it in the bytecode as an argument to the type error
constructor), we can calculate it at exception throwing time, by
re-parsing the source in a similar way to the existing call site
rendering.
This slightly decreases bytecode size and slightly decreases the amount
of work the bytecode compiler needs to do. In the future, it could also
allow us to give more detailed error messages, as we now have access to
the entire AST and are on the slow path anyway.
Bug: v8:6499
Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72
Reviewed-on: https://chromium-review.googlesource.com/c/1396080
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58706}
The 'done' setting dance in BuildFillArrayWithIterator turned out to
not be useful, as the StoreInArrayLiteral call could not ever throw an
exception. Since iterator exceptions count as done, we are guarnteed to
be done as soon as we enter the loop.
Change-Id: Ibe2ba1fcbe383bfcfedb185169890b6931cc7884
Reviewed-on: https://chromium-review.googlesource.com/c/1402792
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58695}
The IteratorClose spec specifies that exceptions in
%GetMethod(iterator.return) are not suppressed by exceptions in the
given continuation (body of a loop, assignments in destructuring),
while exceptions in the execution of iterator.return() are.
This means that we have to split out the property access + a typeof
check to be outside the try-catch, and keep the call inside of it.
The non-split version is only for cases when there is no 'throws'
continuation (as is the case for yield* calling IteratorClose), so
the existing BuildIteratorClose can be renamed to reflect this.
Change-Id: Id71aea4fddd6ffb986bd9aaa09d29615a8800f71
Reviewed-on: https://chromium-review.googlesource.com/c/1402789
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58694}
Emit a single destructuring assignment for destructuring declarations,
which can be desugared by the bytecode generator. This allows us to
remove destructuring desugaring from the parser (specifically, the
pattern rewriter) entirely.
The pattern "rewriter" is now only responsible for walking the
destructuring pattern to declare variables, mark them assigned, and
potentially rewrite scopes for the edge case of parameters with a sloppy
eval.
Note that since the rewriter is no longer rewriting, we have to flip the
VariableProxy copying logic for var re-lookup, so that we now pass the
new VariableProxy to the variable declaration and leave the original
unresolved (rather than passing the original through and rewriting to a
new unresolved VariableProxy).
This change does have some effect on breakpoint locations, due to some
of the available information changing between the parser and bytecode
generator, however the new locations appear to be more consistent
between assignments and declarations.
Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82
Reviewed-on: https://chromium-review.googlesource.com/c/1382462
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58670}
Previously we'd always push variable proxies into the unresolved list of the
current scope, and possibly delete them from the list later in case they end up
being declarations. If variables become assigned, there were two ways to mark
them as such: The preparser would marked the variables tracked on the
PreParserExpression, and the parser would traverse the LHS AST to find and mark
all variables.
After this CL, if the scope already knows it's tracking declarations, the
variables are never added to the unresolved list in the first place. If the
scope is ambigous, it tracks the variable proxies on the side and only adds
them to the unresolved list if they end up being references rather than
declarations. The same list is now used to bulk mark all LHS variables as
assigned; uniformely for both the parser and the preparser.
In a next step we'll also use the scope to create declarations. That way we can
stop tracking variables_ on PreParserExpression altogether.
Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f
Reviewed-on: https://chromium-review.googlesource.com/c/1397669
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58629}
This patch sets the name slot of the private name symbols for
private fields and display the names in error messages of invalid
private field accesses.
TBR: adamk@chromium.org
Bug: v8:8144
Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76
Reviewed-on: https://chromium-review.googlesource.com/c/1374332
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#58601}
- Directly use VisitFunctionLiteral where possible
- Take shortcut for StringLiterals in BuildLoadPropertyKey
Change-Id: Ib5c3de3d2bdd354acbfeb607415854ba90622e89
Reviewed-on: https://chromium-review.googlesource.com/c/1382750
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58595}
This reverts commit dcd75706c0.
Reason for revert: Breaks layout tests, blocks roll, see
https://crrev.com/c/1396602; there are wasm CLs in this range too,
but this CL looks like the most likely culprit.
Original change's description:
> Reland: [Compiler] Ensure unoptimized code generation is context independent.
>
> Now that Asm.js code is also context independent, move code to ensure context independence
> from BytecodeGenerator to FinalizeUnoptimizedCode.
>
> Reland of CL: https://chromium-review.googlesource.com/c/v8/v8/+/1349236
>
> Change-Id: I718090850870c61733e0719d4091ec60bc080ebb
> Reviewed-on: https://chromium-review.googlesource.com/c/1396201
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58558}
TBR=rmcilroy@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I5f547319f31f87777165361747dd42d223fc0b0e
Reviewed-on: https://chromium-review.googlesource.com/c/1396427
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58564}
Now that Asm.js code is also context independent, move code to ensure context independence
from BytecodeGenerator to FinalizeUnoptimizedCode.
Reland of CL: https://chromium-review.googlesource.com/c/v8/v8/+/1349236
Change-Id: I718090850870c61733e0719d4091ec60bc080ebb
Reviewed-on: https://chromium-review.googlesource.com/c/1396201
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58558}
Instead of de-sugaring destructuring assignment in the parser (using the
pattern rewriter), pass the Object/ArrayLiterals through to the bytecode
generator, which can desugar them in-place.
This allows us to decrease the amount of AST node creation, and improve
the generated bytecode using domain-specific knowledge. As a side effect
we partially fix an old execution ordering spec bug.
Currently only implemented for assignments, not declarations, as the
latter has some additional complexity.
Bug: v8:4951
Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe
Reviewed-on: https://chromium-review.googlesource.com/c/1375660
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58512}
A computed property can never be a private field. That's a SyntaxError.
Change the check to a DCHECK.
Bug: v8:5368
Change-Id: I6701b60f3193639f3ccffacda25074d32d5de5b8
Reviewed-on: https://chromium-review.googlesource.com/c/1385267
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58451}
This changes a few bits about how continuation counters are handled.
It introduces a new mechanism that allows removal of a continuation
range after it has been created. If coverage is enabled, we run a first
post-processing pass on the AST immediately after parsing, which
removes problematic continuation ranges in two situations:
1. nested continuation counters - only the outermost stays alive.
2. trailing continuation counters within a block-like structure are
removed if the containing structure itself has a continuation.
R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org
Bug: v8:8381, v8:8539
Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1339119
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58443}
- Reduce ExpressionResultScope size by reusing accessing the generator
from its RegisterAllocationScope member
- Mark the ExpressionResultScope destructor non-virtual since there are
no destructors in subclasses
Change-Id: I3abe1856c091100217c668cd6bd5e7fd96eb8397
Reviewed-on: https://chromium-review.googlesource.com/c/1386485
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58398}
The parser object can now be created on a worker thread, therefore we shouldn't access
global FLAGs during the constructor. Instead move them to the ParseInfo constructor
and set the parser fields based on these. Also avoid accessing always_opt flags in
bytecode-flags - instead accessing it in ParseInfo and propagating to the bytecode
generator.
Also gets rid of unused kUntrustedCodeMitigations flag in UnoptimizedCompilationInfo
BUG=v8:8582
Change-Id: I6e6fdc8cc7865803cb5f334f652abc0e3e4cb3ce
Reviewed-on: https://chromium-review.googlesource.com/c/1375918
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58316}
The kCallOnHeapBuiltin name has gotten very confusing now
that builtins are actually off the heap (and the generated code will
directly call off-heap).
Bug: v8:7777
Change-Id: Ie14069eee2fc11ef9aec64868c50832f6138ae8f
Reviewed-on: https://chromium-review.googlesource.com/c/1379883
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58291}
Currently, Torque's builtin pointers store a Code target underneath and
callsites generate a kArchCallCodeObject opcode. When embedded builtins
are enabled, the call thus first calls the on-heap trampoline, which
finally jumps to the target off-heap builtin code.
This will no longer be possible in jitless mode, since on-heap code must
not be executable.
As a step towards changing the way builtin pointers are called
(function pointers will hold the builtin index as a Smi, and callsites
look up the off-heap target address and jump there), this CL adds a
dedicated opcode for builtin pointer calls to the compiler pipeline.
The calling mechanism itself is unchanged, changes there will happen
in a follow-up.
Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
Bug: v8:7777
Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
Reviewed-on: https://chromium-review.googlesource.com/c/1378175
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58281}
Currently, the runtime IC functions deduce the IC kind and the language
mode from the feedback slot kind. To support feedback free execution
(for V8 lite mode and lazy allocation of feedback vectors) we need to
infer the IC kind even when feedback vectors are not present.
To be able to infer the language mode without feedback vectors, this cl
forces context allocation in cases where we raise the language mode in
the middle of a function. The language mode is the stricter of the
language mode on the SFI and the language mode of the current context.
This cl updates the bytecode handlers to check for valid feedback vectors
and to call into runtime if the feedback vector is not allocated. It also
adds new runtime functions to be able to infer the IC kind when there is no
feedback vector. Most of the builtins and handlers remain unchanged because
they are only used when feedback vector is present.
Bug: v8:8394
Change-Id: I1f77740c0d68ddaa0de076597f5f6bcb2e966d70
Reviewed-on: https://chromium-review.googlesource.com/c/1358516
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58191}
The class declaration regexp in cpplint did not catch classes decorated
by V8_EXPORT, V8_EXPORT_PRIVATE or any other decorator containing
digits.
This will be fixed in https://github.com/google/styleguide/pull/422.
This CL already prepares the code base by fixing all errors that will
be found after that change.
Some follow-up changes were needed to fix implicit conversion that are
not taken any more now.
R=mstarzinger@chromium.org
Bug: v8:8562
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I03713bd04dbc3f54b89a6c857a93463139aa5efd
Reviewed-on: https://chromium-review.googlesource.com/c/1367751
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58143}
Updates the following bytecode handlers to handle cases when feedback
vector is not allocated:
StaDataPropertyLiteral
CreateRegExpLiteral
CreateArrayLiteral
EmptyArrayLiteral
CreateObjectLiteral
GetTemplateObject
ForInPrepare
ForInNext
Bug: v8:8394
Change-Id: I854cca8dd69539f7e8a17dd8eddb0f9f6d42f762
Reviewed-on: https://chromium-review.googlesource.com/c/1362992
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58107}
This is a reland of f849396c3a
Original change's description:
> [nojit] Remove code stubs
>
> All stubs have been migrated to builtins. This CL removes most related
> code.
>
> Bug: v8:7777, v8:5784
> Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad
> Reviewed-on: https://chromium-review.googlesource.com/c/1365284
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58093}
Tbr: mstarzinger@chromium.org,yangguo@chromium.org,jkummerow@chromium.org,bmeurer@chromium.org
Bug: v8:7777, v8:5784
Change-Id: I005ee2a820d49a75a90481d262a310e4ccfd1391
Reviewed-on: https://chromium-review.googlesource.com/c/1367746
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58101}
All stubs have been migrated to builtins. This CL removes most related
code.
Bug: v8:7777, v8:5784
Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad
Reviewed-on: https://chromium-review.googlesource.com/c/1365284
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58093}
(mostly for roots, handles and stack locations).
Thi CL also changes RootVisitor interface to use FullObjectSlots instead of
ObjectSlots.
Bug: v8:8518
Change-Id: I217c7ae176387a8c64f4754e62339727bdb36018
Reviewed-on: https://chromium-review.googlesource.com/c/1366035
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58091}
This reverts commit 38cd61d0e0.
Reason for revert: Layout test http/tests/asmjs/asm-warnings.html fails due to missing context.
See https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/238991
crash log for renderer (pid <unknown>):
STDOUT: <empty>
STDERR: [1:1:1123/024436.020348:FATAL:script_state.h(140)] Check failed: !context.IsEmpty().
STDERR: #0 0x5556817298df base::debug::StackTrace::StackTrace()
STDERR: #1 0x55568167b5fb logging::LogMessage::~LogMessage()
STDERR: #2 0x55568154ed45 blink::ScriptState::From()
STDERR: #3 0x555683047aa9 blink::V8Initializer::MessageHandlerInMainThread()
STDERR: #4 0x5556801793c8 v8::internal::MessageHandler::ReportMessageNoExceptions()
STDERR: #5 0x555680178652 v8::internal::MessageHandler::ReportMessage()
STDERR: #6 0x5556802c2563 v8::internal::PendingCompilationErrorHandler::ReportWarnings()
STDERR: #7 0x55567fc8bcd3 v8::internal::(anonymous namespace)::FinalizeUnoptimizedCode()
STDERR: #8 0x55567fc8b668 v8::internal::Compiler::Compile()
STDERR: #9 0x55567fc8be6b v8::internal::Compiler::Compile()
STDERR: #10 0x55568033a36f v8::internal::__RT_impl_Runtime_CompileLazy()
STDERR: #11 0x5556808f2492 <unknown>
STDERR:
STDERR: [25209:25254:1123/024436.075700:WARNING:crash_handler_host_linux.cc(341)] Could not translate tid, attempt = 1 retry ...
The issue seems to be that we do require the context for when we report a compile error when finalizing the compilation.
Original change's description:
> [Compiler] Ensure unoptimized code generation is context independent.
>
> Now that Asm.js code is also context independent, move code to ensure context independence
> from BytecodeGenerator to FinalizeUnoptimizedCode.
>
> Change-Id: I7738eb3b347ea82764ecd3b5548dc82cb06d2f4e
> Reviewed-on: https://chromium-review.googlesource.com/c/1347483
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57730}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Iaa15e608b35a3396ba51a03f996c6de1330f0016
Reviewed-on: https://chromium-review.googlesource.com/c/1349236
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57785}
Now that Asm.js code is also context independent, move code to ensure context independence
from BytecodeGenerator to FinalizeUnoptimizedCode.
Change-Id: I7738eb3b347ea82764ecd3b5548dc82cb06d2f4e
Reviewed-on: https://chromium-review.googlesource.com/c/1347483
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57730}
This cl updates:
1. Adds a new feedback cell map to specify that no feedback is
collected
2. Checks if feedback vectors are valid before using then when
creating closures
3. Runtime profiler to only tier up functions with feedback
4. Interpreter entry trampoline to check for feedback vector before
using it.
Bug: v8:8394
Change-Id: I0248c8cd35d841c2744b22f4c672fa2e82033f6e
Reviewed-on: https://chromium-review.googlesource.com/c/1339866
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57648}
Emitting unwinding info for builtins for perf to consume doesn't make sense with
embedded builtins so let's just remove the option.
The perf support is meant for code on the heap and the builtins are not there
anymore. If we want perf to be able to unwind through builtins we should emit
the unwinding DWARF information directly into the binary, using the dedicated
.eh_frame ELF section. This would also mean GDB would be able to unwind through
builtins as well which would be great.
Change-Id: I751cc5eb1e6f7c0eeae6b37a42986ae8ea47d6a0
Reviewed-on: https://chromium-review.googlesource.com/c/1340294
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#57641}
This is the first in a series of patches for adding support to execute
without feedback vectors. This cl updates some of the bytecode handlers
to check for feedback before using them. All these bytecodes only collect
type feedback, so their funcitonality would not change. This cl changes the
implementation for following bytecode:
BinaryOperation
CompareOperation
UnaryOperation
Call
Bug: v8:8394
Change-Id: I284bf9c010718c65f3fe76b6f3f4461b5bfa6742
Reviewed-on: https://chromium-review.googlesource.com/c/1333667
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57580}
This marks the InterpreterEntryTrampoline as isolate-independent. With
this change, all builtins are now embedded.
Slight changes were needed to how we deopt into the trampoline. We now
store the entry address within the Interpreter class instead of
embedding the builtin code target.
Bug: v8:7777
Change-Id: If781bf6f06cb2efbab1369ece757f04c343a1b38
Reviewed-on: https://chromium-review.googlesource.com/c/1337734
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57563}
This CL is an experiment to get more performance data from the perf-bots
and will likely lead to regressions. The try-bots (see patcheset 9)
indicate some regressions, but it doesn't seem too bad.
Change-Id: Ia173ab20ee2a4904663db0f4ca2ffb196b203c77
Reviewed-on: https://chromium-review.googlesource.com/c/1319763
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57483}
The lifetime of this list is fairly simple to reason about. There
is no need to allocate it into the zone.
R=leszeks@chromium.org
Change-Id: I9c918f7e5fddc24c943206aa82be859f27acc2fe
Reviewed-on: https://chromium-review.googlesource.com/c/1325610
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57359}
The Ignition statement list visitor will skip the rest of the
statements in the list if it hits a jump statement (like a return
or break), as the rest of the code in the list can be considered
dead.
return;
dead_call(); // skipped
However, since this is at an AST node level, it does not take into
account condition shortcutting:
if(2.2) return;
dead_call(); // not skipped
There is also a second dead code elimination in Ignition compilation, at
the bytecode array writer level, where a bytecodes are not emitted if an
"exit" bytecode (Return, Jump, or a few others) has been written, until
the next basic block starts (i.e. a Bind).
This can cause an issue with statements that resurrect the bytecode
array writer part-way through their visit. An example is try-catch
statements, which save the context to a register, and then Bind to start
the try region.
For the case:
if (2.2) return;
try { // try statement not skipped
...
}
the bytecode writer is called with
OutputReturn() // exit bytecode seen
OutputMove(<context>, r1) // not emitted
Bind(&try_begin) // starts new basic block
// try body
So, the try is emitted, but without saving the context to a register.
This means that the liveness analysis sees the read of that register
(as the output liveness of throwing bytecodes), but does not have a
write to the register, which means that the liveness escapes.
This patch fixes this by using the bytecode array writer dead-code
elimination (i.e. "exit bytecode seen") to inform the statement list
visitor, so that in this example the try statement is not visited at
all.
Bug: chromium:902395
Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1322951
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57350}
As opposed to the register.
For subtle reasons, this fixes a deoptimizer bug with handling return
values in lazy deopt. Since the return values can now only overwrite
the accumulator, there is no danger of overwriting a captured object
that might be later used (since there is no "later").
Bug: chromium:902608
Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942
Reviewed-on: https://chromium-review.googlesource.com/c/1325901
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57349}
If builtins are embedded and we're not generating the snapshot, then
completely skip iterating over the dispatch table, since off-heap
bytecode handlers can never move or be collected.
Additionally the dispatch table is initialized elsewhere so skip
iterating over the table completely when serializing/deserializing.
Bug: chromium:902230
Change-Id: I2cfe5b4b325d100145d5759ff97e0c8dde7ed7a3
Reviewed-on: https://chromium-review.googlesource.com/c/1319750
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57312}
Rename variables and flag names so that the classes can be reused
by private methods implementation.
In particular:
Rename "fields" to "members" in the initializer so that we can
initialize both fields and private methods/accessors there,
for example:
instance_fields_initializer -> instance_members_initializer
InitializeClassFieldsStatement -> InitializeClassMembersStatement
Rename "private field" to "private name" for the private symbols
used to implement private fields so that we can use them to
store private methods/accessors later as well, for example:
private_field_name_var -> private_name_var
NewPrivateFieldSymbol -> NewPrivateNameSymbol
The follow-on is in
https://chromium-review.googlesource.com/c/v8/v8/+/1301018
The design doc is in
https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing
Bug: v8:8330
Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe
Reviewed-on: https://chromium-review.googlesource.com/c/1312597
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57289}
Now that lazy deserialization has been removed, we can roll back all
the mechanisms we introduced to support lazy single-builtin
deserialization.
This CL moves serialized builtin code objects (i.e.
off-heap-trampolines in most cases) back into the startup snapshot.
Support classes for builtin serialization and deserialization, as well
as the builtins snapshot itself are removed. Templatization on the
allocator class is removed as well.
Tbr: delphick@chromium.org
Bug: v8:6666, v8:7990
Change-Id: I2a910f8d3278b7e27b5f18ad408361ebd18871cc
Reviewed-on: https://chromium-review.googlesource.com/c/1304539
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57160}
Now that embedded builtins are enabled everywhere*, lazy
deserialization can be turned off and removed.
* Except nosnap builds, on aix and in msvc builds.
Bug: v8:6666, v8:6624, v8:7990
Change-Id: Ib5fefe10e7ff35b13a1eb803fbc3736b8851b22b
Reviewed-on: https://chromium-review.googlesource.com/c/1288638
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57064}
This is a reland of 9cde880856 now the the underlying
problem in Chromium is fixed by:
https://chromium-review.googlesource.com/c/chromium/src/+/1301459
Original change's description:
> [Compile] Ensure we don't access the native context during bytecode finalization.
>
> Resets the isolate's context to nullptr in debug builds during bytecode finalization
> to ensure that we don't rely on the native context during context independent
> unoptimized compilation.
>
> BUG=chromium:898076, v8:8041
>
> Change-Id: Ifaa5006a7a3d31d7fbd535ebb63f8889c75526c4
> Reviewed-on: https://chromium-review.googlesource.com/c/1297961
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56979}
TBR=leszeks@chromium.org
Bug: chromium:898076, v8:8041
Change-Id: I11904e19e843b0eadab698196ac1ef9c7aeec766
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel; luci.chromium.try:linux_chromium_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1301480
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57048}
Resets the isolate's context to nullptr in debug builds during bytecode finalization
to ensure that we don't rely on the native context during context independent
unoptimized compilation.
BUG=chromium:898076, v8:8041
Change-Id: Ifaa5006a7a3d31d7fbd535ebb63f8889c75526c4
Reviewed-on: https://chromium-review.googlesource.com/c/1297961
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56979}
This CL introduces a ScopedPtrList that's a view over an underlying ZonePtrList
buffer. Whenever a ScopedPtrList is the top-of-stack list, you can add values
through it, which will add them to the end of the buffer. Once the list is
done, you can copy out the values to a real ZonePtrList. That way you do not
need to guess what the required size of the list is, and you get better cache
locality.
Change-Id: I2d229d73bb25bbb450ae5b6767ab100abad2b3a3
Reviewed-on: https://chromium-review.googlesource.com/c/1296458
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56939}
as part of the continuing quest to get rid of Object*/Object**.
This is a fairly mechanical replacement of Object**/MaybeObject** with
wrapper objects carrying the same data. No change in behavior is intended.
Overloaded operators are provided to minimize code churn.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I76cee82b8bf2dd80a1b66f09dd2bb2b65038eeb7
Reviewed-on: https://chromium-review.googlesource.com/c/1287889
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56920}
This patch merges ClassLiteralProperty::PUBLIC_FIELD and
ClassLiteralProperty::PRIVATE_FIELD into ClassLiteralProperty::FIELD,
and moves the visibility part into ClassLiteralProperty::is_private()
for the ease of adding new combinations in the future.
Bug: v8:8330
R=gsathya@chromium.org
Change-Id: I54f64d05bccb1867d9111e4c80158a6075406d80
Reviewed-on: https://chromium-review.googlesource.com/c/1291052
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#56910}
Typically compiler does not have to compile one-shot code but, there
are some cases where user can capture IIFEs and execute it multiple times.
Adding counter to track number of such closures compiled with one-shot
bytecodes.
Bug: v8:8072
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I752a12cff6ee9bb751323f4d58897cdd41c6890c
Reviewed-on: https://chromium-review.googlesource.com/c/1237679
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56862}
Previously when class names were computed and set as part of
StoreDataPropertyInLiteral calls, it was observable to static fields
as these static fields are initialized right after the classes were
constructed but before the class names were installed.
This caused the name property to be undefined for this case.
Instead, this patch always forces the creation of a name property on
the class constructor when static class fields are used. This patch
does kill the class boilerplate optimization, but currently all static
class fields are installed using a runtime call to CreateDataProperty
so this isn't any worse when using static class fields.
In the future, this can be optimized away by storing the name on the
boilerplate.
There is spec discussion here:
https://github.com/tc39/proposal-class-fields/issues/85
There isn't a resolution yet, there's still discussion about whether
to have the name be undefined always for static class field
initializers. But, I don't think that's useful as it would always kill
our boilerplate optimization (like this patch does ..., but without the
future optimization potential).
Bug: v8:5367
Change-Id: I14afdf7ece3f2d9fa3c659d2c0bc3806e0b17abb
Reviewed-on: https://chromium-review.googlesource.com/c/1281002
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56686}
This JSAsyncFunctionObject represents the implicit generator object
inside of async functions, and also holds the outer promise for the
async functions. This in turn allows us to get rid of the .promise
in the Parser / BytecodeGenerator completely, and will make it
possible to build zero-cost async stack traces independent of the
concrete synchronous part of the stack frame (which currently breaks
in Node.js).
In the bytecode all the async function operations now take this new
JSAsyncFunctionObject instead of passing both the .generator_object
and the .promise, which further simplifies and shrinks the bytecode.
It also reduces the size of async function frames, potentially making
the suspend/resume cheaper.
This also changes `await` to use intrinsics instead of calling to
special JSFunctions on the native context, and thus reduces the size of
the native contexts.
Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
to TurboFan.
Bug: v8:7253, v8:7522
Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1273049
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56554}
This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.
We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.
In essence we now turn an async function like
```js
async function f(x) { return await bar(x); }
```
into something like this (in Parser and BytecodeGenerator respectively):
```
function f(x) {
.generator_object = %_AsyncFunctionEnter(.closure, this);
.promise = %AsyncFunctionCreatePromise();
try {
.tmp = await bar(x);
return %_AsyncFunctionResolve(.promise, .tmp);
} catch (e) {
return %_AsyncFunctionReject(.promise, e);
}
}
```
Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function
```js
async function f(x) { return await x; }
```
goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.
Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!
Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
... by removing entries corresponding to read only roots (which are
immortal immovable by definition) and using READ_ONLY_ROOT_LIST explicitly.
This CL also renames the list to MUTABLE_IMMORTAL_IMMOVABLE_ROOT_LIST and
moves Heap::RootIsImmortalImmovable() to RootsTable::IsImmortalImmovable().
Bug: v8:8238
Change-Id: I3e44a06d7a816955bc3471e788e883fb053b03d9
Reviewed-on: https://chromium-review.googlesource.com/c/1269035
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56466}
See https://chromium-review.googlesource.com/1219025 for the corresponding
MaybeObject renaming.
BUG=v8:7308
Change-Id: Ib454fd53d12f110da289e1d3e1e12411b016e557
Reviewed-on: https://chromium-review.googlesource.com/c/1267937
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56443}
For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.
Some drive-by cleanups:
- Remove the switch in NameForRuntimeId() and just use the table of
runtime functions to lookup the name directly.
- Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
they are the last users of the inline versions of these.
- Remove the MaxSmi inline version as it is only used in tests.
Saves 64 KiB binary size.
Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
This is a reland of eccf186749
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
Bug: v8:8072
Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
Reviewed-on: https://chromium-review.googlesource.com/1245742
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56266}
This reverts commit eccf186749.
Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com
Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8072
Reviewed-on: https://chromium-review.googlesource.com/1245421
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56232}
Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
for one-shot property loads and stores. This CL replaces the runtime
calls with new bytecodes for named property load stores in one-shot code.
the runtime calls needed extra set of consecutive registers and
additional move instructions. This increased the size of
bytecode-array and possibly extended the life time of objects.
By replacing them with NoFeedback bytecodes we avoid these issues.
Bug: v8:8072
Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
Reviewed-on: https://chromium-review.googlesource.com/1196725
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#56211}
In an embedded handler build, it's not guaranteed that every handler
is embedded (and thus immovable). The GC must still iterate the
dispatch table to update pointers to moved code objects.
TBR=rmcilroy@chromium.org
Bug: v8:8068
Change-Id: I8b37f1758fdc670081e0c4f58795aea271811994
Reviewed-on: https://chromium-review.googlesource.com/1238236
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56148}
Handlers were recently moved to the builtins table, and we never added
full support for this flag. It doesn't add much value and lazy
deserialization is scheduled for mid-term removal anyways, so let's
just delete it.
--lazy-deserialization now controls both builtin- and
handler-deserialization behavior.
Bug: v8:6624
Change-Id: Iffb7286a00157966abf99158ba629ce4765536d6
Reviewed-on: https://chromium-review.googlesource.com/1238235
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56117}
Even in the embedded bytecode handler configuration, there's currently
no guarantee that all handlers are eager. Specifically, on ia32
handlers are currently not embedded and thus lazy.
We need to keep lazy deserialization logic around until that is no
longer the case.
Bug: v8:6624
Change-Id: Ie4ec5f0fcd9890ed96a5df3bf3654e85379f92ae
Reviewed-on: https://chromium-review.googlesource.com/1236261
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56110}
Refactors the CompilerDispatcher to be able to enqueue eager inner functions
for off-thread compilation during top-level compilation of a script.
Unoptimized compile jobs are simplified to only have two phases - compile
and finalization. Only finalization requires heap access (and therefore
needs to be run on the main thread). The change also introduces a requirement
to register a SFI with a given compile job after that job is posted, this
is due to the fact that an SFI won't necessarily exist at the point the job
is posted, but is created later when top-level compile is being finalized.
Logic in the compile dispatcher is update to deal with the fact that a job
may not be able to progress if it doesn't yet have an associated SFI
registered with it.
BUG=v8:8041
Change-Id: I66cccd626136738304a7cab0e501fc65cf342514
Reviewed-on: https://chromium-review.googlesource.com/1215782
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56088}
The following runtime functions (and their intrinsic counter parts) are
completely unused/obsolete by now
- %ToInteger
- %GeneratorGetInputOrDebugPos
and in addition the intrinsics for %_ToNumber and %_IsJSProxy are also
dead (according to code coverage and manual verification), so drop them
as well (their runtime function counterparts are still somewhat used).
Bug: v8:8015
Change-Id: I60d53762dd9717fb43de38cb490b46676c467212
Reviewed-on: https://chromium-review.googlesource.com/1235923
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56076}
This always creates the bytecode handlers as part of the builtins table
regardless of the V8_EMBEDDED_BYTECODE_HANDLERS definition.
Lazy deserialization of bytecode handlers is enabled for this flow by
moving the three lazy bytecode deserializers from the strong roots into
the builtins table (ensuring that they not marked lazy themselves).
To simplify lazy deserialization, the illegal bytecode handler is made
non-lazy so that GetAndMaybeDeserializeBytecodeHandler doesn't to know
about it.
Since the bytecode handlers are now always part of the builtins table,
many bytecode specific methods are removed, including logging and in
BuiltinsSerializer and BuiltinsDeserializer.
Removes setup-interpreter.h, setup-interpreter-internal.cc and
builtin-snapshot-utils.*.
Change-Id: Ie421aa897a04f7b3bcb964c476eb7ab149388d53
Reviewed-on: https://chromium-review.googlesource.com/1220046
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56063}
IIFE`s within a function are not guaranteed to be executed only once.
They can be called multiple times and compiler can inline them.
Do the one-shot optimizations only for IIFE`s from top-level code.
Bug: v8:8072, chromium:886580
Change-Id: I02370681cc3eab270edcc75ee120ca7ad768ed52
Reviewed-on: https://chromium-review.googlesource.com/1231174
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56024}
We do not have to collect feedback for function calls in one-shot code.
This CL avoids allocating CallICslots for each function call by
emitting CallNoFeedback bytecodes. We save one CallICSlot (two entries
in feedback vector) per function call in One-shot.
Bug: v8:8072
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic2580e5972acd5124c2e71d540985736ce797fe8
Reviewed-on: https://chromium-review.googlesource.com/1178051
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55951}
The macro has been deprecated since 2016, and it keeps confusing me, so
let's just remove it completely from the code base.
R=leszeks@chromium.orgTBR=mstarzinger@chromium.org, verwaest@chromium.org, jgruber@chromium.org
Bug: v8:8015
Change-Id: Ibe1122fd9d2624bc94873d9c51dc8499c54a04fd
Reviewed-on: https://chromium-review.googlesource.com/1209322
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55779}
Previously the builtins table had a value for every single
OperandScale/Bytecode combination regardless of whether it was valid.
This change makes it so that only valid bytecode handlers are stored in
the builtins table. This prevents placeholders being serialized into the
snapshot (and embedded into the binary) saving 9KB in
CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66
entries in the builtins table.
To do this, it generates a new header file bytecodes-builtins-list.h
which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros.
Since list macros cannot be used to conditionally generate elements in
the C-preprocessor, this is done by generator executable, compiled from
interpreter/generate-flat-headers.cc.
Additionally the generator creates the flat bytecode list so that it is
transposed from the previous result, i.e. the results are grouped by
bytecode and then operand scale rather than operand scale then bytecode.
This should give better locality for commonly used bytecodes and may
allow less commonly used ExtraWide bytecodes to never be mapped into
memory at all.
The cost to storing the handlers densely is that looking up a handler
now requires a binary search through the builtins table, but this should
only happen during debugging. It is also fixable at least for non-wide
handlers and could be improved for wide ones if the need arises.
Bug: v8:8068
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667
Reviewed-on: https://chromium-review.googlesource.com/1209304
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55757}
This is a reland of 1c48d52bb1.
It turned out that IterableToList doesn't always behave according to
the ES operation with the same name. Specifically, it allows holey arrays
to take its fast path, which produces an output array with holes where
actually "undefined" elements should appear.
This CL changes the version of IterableToList that is used for spreads
(IterableToListWithSymbolLookup) such that holey arrays take the slow path.
It also includes tests for such situations.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
Bug: v8:7980
Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201882
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55639}
When v8_enable_embedded_bytecode_handlers is true, initialize the
bytecode dispatch table from the builtins table. Also stops creating
the handlers more than once as the SetupInterpreter will now always do
nothing even when not starting from a snapshot.
In the short term, with the flag enabled all the bytecode handlers are
eagerly deserialized.
Finally, the bytecode handlers are marked as non-isolate independent to
prevent them being embedded in the binary until they can be converted.
Bug: v8:8068
Change-Id: I9e5ef7f1dce1b2d11c7aa26526f06b53f8939697
Reviewed-on: https://chromium-review.googlesource.com/1188477
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55581}
This reorders arguments in preparation for removing ebx from its
calling convention (in a follow-up some args will be passed on the
stack).
Drive-by: Improve readability in the code handling different cases
(array,spread,...).
Bug: v8:6666
Change-Id: I0160f8efafd0fd0e841739578e01c32b38adb66e
Reviewed-on: https://chromium-review.googlesource.com/1196884
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55557}
This reverts commit 1c48d52bb1.
Reason for revert: Clusterfuzz found something.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
In the KeyedLoadICGeneric case the engine previously immediately fell
back to the %KeyedGetProperty runtime function if the key was not a
Name or a valid array index. This turns out to be really slow if a
program passes for example objects as keys. Since we already have all
the logic in place to convert an arbitrary JavaScript value to a Name,
we can just call into ToName first and then operate on the result of
that, which is significantly faster since C++ usually doesn't need to
call back into JavaScript then to convert a JSReceiver into a Name.
This also changes the ToName builtin to use the existing builtin for
NonPrimitiveToPrimitive, which stays in JavaScript land completely.
Since there's not really a point in inlining ToName into the call
sites, the other uses were also changed to call the builtin instead,
which saves some space and might also help with instruction cache
utilization (especially when the ToName logic is more involved now).
This improves the performance on the microbenchmark
```js
const n = 1e7;
const obj = {};
const key = [1,2];
const start = Date.now();
for (let i = 0; i < n; ++i) {
if (obj[key] === undefined) obj[key] = key;
}
print(`time: ${Date.now() - start} ms.`);
```
by up to 36%. On the ARES-6 ML benchmark the steady state improves by up
to ~7% and the overall mean for ARES-6 ML improves by up to ~6%. Further
improvements might be possible here if the GetProperty builtin could be
made faster for common prototype lookups like Symbol.toPrimitive and the
"valueOf" and "toString" functions.
Bug: v8:6344, v8:6670
Change-Id: Ic3ac2bc4d4277836ef03039de4eda5c5f66a85da
Reviewed-on: https://chromium-review.googlesource.com/1199022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55540}
This CL improves the performance of creating [...a, b] or [...a].
If the array literal has a leading spread, this CL emits the bytecode
[CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
is implemented by [IterableToListDefault] builtin to create the initial
array for the leading spread. IterableToListDefault has a fast path to
clone efficiently if the spread is an actual array.
The bytecode generated is now shorter. Bytecode generation is refactored
into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
from this optimization also.
For now, turbofan also lowers the bytecode to the builtin.
The idiomatic use of [...a] to clone the array a now performs better
than a simple for-loop, but still does not match the performance of slice.
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
Reviewed-on: https://chromium-review.googlesource.com/1181024
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55520}
Use BuiltinAssemblerOptions to generate AssemblerOptions when generating
the bytecode handlers (assuming v8_enable_embedded_bytecode_handlers is
on).
Mark all but InvokeIntrinsic, InvokeIntrinsicWide,
InvokeIntrinsicExtraWide, TestIn, TestInWide, TestInExtraWide and
TestTypeOf as isolate-independent. The excluded handlers create jump
tables which have absolute addresses.
Bug: v8:8068
Change-Id: Ia29e9c737ec345193e24fc2aa3684daefb113a9a
Reviewed-on: https://chromium-review.googlesource.com/1195508
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55514}
The SharedFeedbackSlot helper class allow bytecodes to share one feedback
slot. The helper will only create the slot on-demand, at the first-use.
This does not encapsulate the use-case of FeedbackSlotCache.
Change-Id: I22aec19d59e52e7395898fa2a59c5c1ec95abbe8
Reviewed-on: https://chromium-review.googlesource.com/1189904
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55452}
This doubles the size of the snapshot since it creates all of the
handlers twice (and it doesn't use any of these new ones). However it's
all behind a flag.
For now all bytecode handlers are marked as being not Isolate
independent to prevent snapshot creation failures.
Bug: v8:8068
Change-Id: Id49f521445643d9fc6b141353f0a29b585160e10
Reviewed-on: https://chromium-review.googlesource.com/1185100
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55411}
No need to create allocation site for array literals in oneshot code since
they are executed only once. The interpreter emits a runtime call to
CreateArrayLiteralWithoutAllocationSite for creating literals in
oneshot code instead.
Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1
Reviewed-on: https://chromium-review.googlesource.com/1167843
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55349}
Also update comments that'd gotten unnecessarily verbose over
ten years of language development.
Bug: v8:8015
Change-Id: I6688ce22e4aa92f66f937159d890b9922f109d43
Reviewed-on: https://chromium-review.googlesource.com/1180357
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55288}
This removes a couple of intrinsics/runtime functions/macros that are no
longer needed at all (or not in TurboFan for performance reasons).
Bug: v8:8015
Change-Id: I08ae8de7cc63019eb30d3b71dd1c824d6392076a
Reviewed-on: https://chromium-review.googlesource.com/1183481
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55277}
This should make the uses of binary vs. bitwise not very clear:
- Word32BinaryNot for logical negation
- Word32BitwiseNot for bitwise negation
Change-Id: I3345913111da0dbdae6fdf285f090b67eb3f3afc
Reviewed-on: https://chromium-review.googlesource.com/1169205
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55091}
No need to create allocation site for literals in oneshot code since
they are executed only once. The interpreter emits a runtime call to
CreateObjectLiteralWithoutAllocationSite for creating literals in
oneshot code instead.
Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403
Reviewed-on: https://chromium-review.googlesource.com/1163615
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55050}
This CL changes the order of the parameters of HasProperty to be
more consistent with other CSA macros.
Drive-by-change: Use HasProperty stub directly in Torque.
R=jgruber@chromium.org
Bug: v8:8015
Change-Id: I73d1096afbb86d52e2af67c1969549f1158448a7
Reviewed-on: https://chromium-review.googlesource.com/1166831
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55025}
This is a reland of 690bda84eb
Original change's description:
> [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code
>
> An IIFE or top-level code is executed only once hence, there is no need to collect
> type feedback. We can save some memory by not using IC slots for property Loads/Stores
> within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty
> /StaNamedProperty for the property loads within a IIFE and top-level code.
>
> Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9
> Reviewed-on: https://chromium-review.googlesource.com/1146579
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#54949}
Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5
Reviewed-on: https://chromium-review.googlesource.com/1167802
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55017}
This reverts commit 690bda84eb.
Reason for revert: Speculative revert for:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/25372
See more at:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original change's description:
> [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code
>
> An IIFE or top-level code is executed only once hence, there is no need to collect
> type feedback. We can save some memory by not using IC slots for property Loads/Stores
> within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty
> /StaNamedProperty for the property loads within a IIFE and top-level code.
>
> Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9
> Reviewed-on: https://chromium-review.googlesource.com/1146579
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#54949}
TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,yangguo@chromium.org,cbruni@chromium.org,leszeks@chromium.org,verwaest@chromium.org,chandanreddy@google.com
Change-Id: I642164a72453189fd0fe92b69f199f958ce56bef
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1166782
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54955}
An IIFE or top-level code is executed only once hence, there is no need to collect
type feedback. We can save some memory by not using IC slots for property Loads/Stores
within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty
/StaNamedProperty for the property loads within a IIFE and top-level code.
Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9
Reviewed-on: https://chromium-review.googlesource.com/1146579
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#54949}
Includes fixes for several ClusterFuzz regressions:
1) fix an invalid Handle-cast in ic.cc (chromium:866282)
2) fix for improper accounting of used/unused inobject
fields, found by clusterfuzz (chromium:866357).
3) fix number of control outputs for the JSCloneObject
operator to be used by IfSuccess and IfException nodes (chromium:866727).
4) fix property constness in out-of-object properties of fast-cloned
object to be compatible with DCHECKs in StoreIC (chromium:866861).
Also includes the fixups missing from the initial commit, and
regression tests
BUG=v8:7611, chromium:866282, chromium:866357, chromium:866727, chromium:866861
R=jkummerow@chromium.org, mvstanton@chromium.orgTBR=rmcilroy@chromium.org
Change-Id: I77220308482f16db2893c0dcebec36530d0f5540
Reviewed-on: https://chromium-review.googlesource.com/1146297
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54706}
This reverts commit 29379945b6.
Reason for revert: Needed for other revert:
https://chromium-review.googlesource.com/c/v8/v8/+/1145431
Original change's description:
> [cleanup] Rename {kLastErrorMessage} to {kNumberOfReasons}
>
> The name {kLastErrorMessage} is misleading, as it's not actually the
> index of the last message (or reason), but one more (i.e. number of
> messages / reasons). Thus this renaming.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7754
> Change-Id: Id21edcecac84c0e6068423c6124ef2881116dc7c
> Reviewed-on: https://chromium-review.googlesource.com/1145305
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54593}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I2af83f4a2299e05ad9bcacfe69c0b483fd1488de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7754
Reviewed-on: https://chromium-review.googlesource.com/1145520
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54596}
