The SwitchOnGeneratorState bytecode now also falls through if the
generator object is undefined (so that we don't need that jump) and
restores generator context (so that we don't need that PushContext).
This saves 10 bytes per generator.
Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620
Reviewed-on: https://chromium-review.googlesource.com/867051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50845}
Instead of building suspend_ids in the AST numbering, collect suspend
counts in the parser and assigning suspend ids during bytecode
generation.
Bug: v8:7178
Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0
Reviewed-on: https://chromium-review.googlesource.com/817598
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50830}
Currently, yields and awaits inside loops compile to bytecode which
switches to the top of the loop header, and switch again once inside the
loop. This is to make loops reducible.
This replaces this switching logic with a single switch bytecode that
directly jumps to the bytecode being resumed. Among other things, this
allows us to no longer maintain the generator state after the switch at
the top of the function, and avoid having to track loop suspend counts.
TurboFan still needs to have reducible loops, so we now insert loop
header switches during bytecode graph building, for suspends that are
discovered to be inside loops during bytecode analysis. We do, however,
do some environment magic across loop headers since we know that we will
continue switching if and only if we reached that loop header via a
generator resume. This allows us to generate fewer phis and tighten
liveness.
Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
Reviewed-on: https://chromium-review.googlesource.com/866734
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50804}
Instead of requiring the pattern that a SuspendGenerator must be
followed by a Return, make SuspendGenerator return directly. This can,
in the future, simplify some of the reasoning around generator suspends.
Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5
Reviewed-on: https://chromium-review.googlesource.com/857463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50748}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.orgTBR=neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
Reviewed-on: https://chromium-review.googlesource.com/857593
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50518}
This makes RestoreGeneratorRegisters do a fuller resume process: update
the state register to indicate that it is now executing, and update the
accumulator with the input_or_debug_pos of the generator - i.e., perform
the boilerplate generator resuming in one bytecode instead of several.
Change-Id: Ia87b6766ac023064b40d3e9a143e7b32118ea3a0
Reviewed-on: https://chromium-review.googlesource.com/859770
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50499}
This reverts commit bf4cc9ee15.
Reason for revert: Breaks windows with msvc and linux with gcc
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
Original change's description:
> [esnext] load `iterator.next` only once at beginning of iteration
>
> https://github.com/tc39/ecma262/pull/988 gained concensus during the
> september 2017 TC39 meetings. This moves the load of the "next" method
> to the very beginning of the iteration protocol, rather than during
> each iteration step.
>
> This impacts:
>
> - yield*
> - for-of loops
> - spread arguments
> - array spreads
>
> In the v8 implementation, this also affects async iteration versions of
> these things (the sole exception being the Async-From-Sync iterator,
> which requires a few more changes to work with this, likely done in a
> followup patch).
>
> This change introduces a new AST node, ResolvedProperty, which can be used
> as a callee by Call nodes to produce the same bytecode as Property calls,
> without observably re-loading the property. This is used in several
> AST-desugarings involving the iteration protocol.
>
> BUG=v8:6861, v8:5699
> R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
> Reviewed-on: https://chromium-review.googlesource.com/687997
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50452}
TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6861, v8:5699
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/857616
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50454}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
Reviewed-on: https://chromium-review.googlesource.com/687997
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50452}
This is just a rebased version of
https://chromium-review.googlesource.com/c/v8/v8/+/571453 with
no functional changes
Bug: v8:6889
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765
Reviewed-on: https://chromium-review.googlesource.com/849423
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50417}
Create a new function kind for initializer functions and ban arguments
if used in such a function.
Bug: v8:5367, v8:7183
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id3089e587b3d6a25f27224045f250e032b831818
Reviewed-on: https://chromium-review.googlesource.com/850547
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50369}
This patch breaks out bailout reasons into two enum classes.
This helps save 3 bits on the SharedFunctionInfo as we don't have to
track the abort reasons.
Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97
Reviewed-on: https://chromium-review.googlesource.com/848244
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50364}
The bytecode generator has special handling for comparing the result of
the typeof operator against a string literal. This needs to be adapted
for bigints.
R=jkummerow@chromium.org, mythrie@chromium.org
Bug: v8:6791
Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c
Reviewed-on: https://chromium-review.googlesource.com/753465
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49172}
Currently, dynamic `import()` throws the following SyntaxError when
used without a specifier:
> import();
< Uncaught SyntaxError: Unexpected token )
From the error message, it seems this the result of the code snippet
being seen as static `import` followed by parens, as opposed to
`import()` with no specifier.
This patch makes this error message more clear:
> import();
< SyntaxError: import() requires a specifier
BUG=v8:7020,v8:6513
Change-Id: I3519dfd0029f38d23da858a5499f1d226e794935
Reviewed-on: https://chromium-review.googlesource.com/747141
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49058}
... and use them to complete the BigInt function.
Bug: v8:6791
Change-Id: Ia36db86b92d1a0cfcb783516e04d6c0e3750f194
Reviewed-on: https://chromium-review.googlesource.com/737643
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48993}
Moves the feedback vector slot allocation out of ast-numbering and into
bytecode generation directly. This has a couple of benifits, including reduced
AST size, avoid code duplication and reduced feedback vector sizes in many cases
due to only allocating slots when needed. Also removes AstProperties since
this is no longer needed.
AstNumbering is now only used to allocate suspend ids for generators.
BUG=v8:6921
Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f
Reviewed-on: https://chromium-review.googlesource.com/722959
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48757}
This introduces a ToNumeric conversion to the runtime and interpreter.
ToNumeric behaves like ToNumber, except that it also lets BigInts pass.
Bug: v8:6791
Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7
Reviewed-on: https://chromium-review.googlesource.com/707013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48440}
The specced semantics of GetSubstitution are expected to change in the
case of malformed named references, or named references to nonexistent
named groups. The former will evaluate to the identity replacement of
'$<', while the latter will result in replacement by the empty string.
See also:
https://github.com/tc39/proposal-regexp-named-groups/issues/29
Bug: v8:5437, v8:6912
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I879288f775774cb0ec563f9d9129a99710efb77c
Reviewed-on: https://chromium-review.googlesource.com/708654
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48426}
Rewrites import.meta expressions into null literals. Builds on top
of- and requires dynamic import parsing to simplify the implementation.
Adds a new --harmony-import-meta flag.
BUG=v8:6693
Change-Id: Iadb7ddf6bad8986bf3ad641dbd3826fe730b5f44
Reviewed-on: https://chromium-review.googlesource.com/702678
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48359}
This reverts commit d0651bd108.
Reason for revert: Breaks gc stress with embedded snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355
Original change's description:
> [language] Implement optional catch binding proposal
>
> This allows the syntax `try {} catch {}` (with no binding after the
> `catch`).
>
> See https://github.com/michaelficarra/optional-catch-binding-proposal/
>
> Currently behind --harmony-optional-catch-binding.
>
> As part of the implementation, this allows TryCatchStatements to not
> have an associated catch scope; various paths which assumed they
> would have been updated to handle this case.
>
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f
> Reviewed-on: https://chromium-review.googlesource.com/571453
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Kevin Gibbons <bakkot@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#48300}
TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com
Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/702334
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48303}
This allows the syntax `try {} catch {}` (with no binding after the
`catch`).
See https://github.com/michaelficarra/optional-catch-binding-proposal/
Currently behind --harmony-optional-catch-binding.
As part of the implementation, this allows TryCatchStatements to not
have an associated catch scope; various paths which assumed they
would have been updated to handle this case.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f
Reviewed-on: https://chromium-review.googlesource.com/571453
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Kevin Gibbons <bakkot@gmail.com>
Cr-Commit-Position: refs/heads/master@{#48300}
This CL teaches the respective bytecode handlers and standalone stubs
about BigInts, and collects "kBigInt" feedback for them. However,
Turbofan does not yet care about such feedback, so it is simply converted
to "any" for now (making TF emit stub calls for BigInt operations).
Bug: v8:6791
Change-Id: I6440c108ccd79058d77adc2a6041251db9d5f81d
Reviewed-on: https://chromium-review.googlesource.com/683758
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48173}
This patch ensures a `TypeError` is thrown when the argument passed to
`Array.prototype.sort` or `%TypedArray%.prototype.sort` is neither a
function nor `undefined`.
Every other major JavaScript engine already threw in this case. Making
V8’s behavior match increases interoperability.
https://github.com/tc39/ecma262/pull/785
BUG=v8:6542
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I412a59810abdd118217c8d8361389ec6c2f640bd
Reviewed-on: https://chromium-review.googlesource.com/668356
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48028}
The advantage of an explicit Abort that the interpreter and the compiler know
that aborting cannot continue or throw or deopt. As a result we generate less
code and we do not confuse the compiler if the environment is not set up for
throwing (as in the generator dispatch that fails validation in
crbug.com/762057).
Bug: chromium:762057
Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7
Reviewed-on: https://chromium-review.googlesource.com/657025
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47922}
For deferred commands (such as in try-finally), some deferred commands
save and restore the accumulator using a result register (e.g. return,
throw, rethrow), while others don't (e.g. break, continue,
fall-through).
However, conditionally reading this result register that may not ever be
written caused it to be considered live from the start of the function,
as far as the liveness analysis could statically tell.
Now, we write the result register for all deferred commands, including
the fall-through. As a micro-optimization, we re-use the Smi command
tokeen to clobber the result, rather than emitting an LdaUndefined.
Bug: chromium:758472
Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b
Reviewed-on: https://chromium-review.googlesource.com/635592
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47612}
Move the desugaring into BytecodeGenerator per TODOs.
BUG=v8:6472
R=tebbi@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org
Change-Id: Ic482bee18d6e6fe73de4c5f9abaf4feda7be2dd5
Reviewed-on: https://chromium-review.googlesource.com/550396
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47403}
Removes the new.target slot from the interpreter's fixed frame. Instead
adds a field to BytecodeArray to get the bytecode's incoming
new.target or generator object register. The InterpreterEntryTrampoline
then sets this register with the incoming new.target (or generator object)
when the function is called. This register can be directly the new.target
or generator object variable if they are LOCAL location, otherwise it is a
temporary register which is then moved to the variable's location during the
function prologue.
This fixes a hack in the deoptimizer where we would set the new.target fixed
slot to undefined in order to avoid extending it's lifetime through the
optimized code - now it's just a standard register and can be optimized away
as normal.
Bug=v8:6644
Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
Reviewed-on: https://chromium-review.googlesource.com/608966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47320}
Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.
Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.
BUG=v8:6409
Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
AsyncGenerators, when resumed with a "return" completion, Await the sent
value to provide consistency with syntactic return statements. This
moves the await to during AsyncGeneratorResumeNext, shrinking the number
of bytecodes.
There's a minor change to BytecodeGenerator which removes a
%_GeneratorClose() call, since it's inserted implicitly by the parser.
BUG=v8:5855
TBR=neis@chromium.org
Change-Id: I2965c610e5985ac24c713b481e62f6b97f96a3d8
Reviewed-on: https://chromium-review.googlesource.com/582218
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47253}
- Previous fix is https://chromium-review.googlesource.com/c/583531 but it
diverges Scopes created by PreParser from Scopes created by Parser.
- This CL creates the inner block scope a bit earlier and (temporarily) pushes
it into the scope chain for parsing the variable declarations in a for
loop. The previous approach was to first parse the variable declarations and
then reparent the AST nodes / Scopes created while parsing it afterwards.
- This CL partially reverts https://chromium-review.googlesource.com/c/583531;
the new fix only touches parser-base.h (diff between patch sets 2 and 3 is the
fix).
- The Ignition golden changes are basically undoing the changes done in that CL
too.
Bug: chromium:740591
Change-Id: Iceff1383ef066317e754942bb5ff0c70a91bc937
Reviewed-on: https://chromium-review.googlesource.com/603787
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47241}
A spec change (a0dfeba1a8) introduced a number of Await operations to the spec. In turn, this caused generated bytecode for async generators to grow drastically.
This commit moves the Await within AsyncGeneratorYield (https://tc39.github.io/proposal-async-iteration/#sec-asyncgeneratoryield step 5) into a new TFJ builtin, similar in structure to AsyncGeneratorAwait, but instead of resuming the generator on resolution of the Promise, the current generator request's Promise is fulfilled instead.
This results in a reduction in generated bytecode without losing any statically available information.
BUG=v8:5855
Change-Id: Ib5bcf06132d221beffdea30639a7b4437030143b
Reviewed-on: https://chromium-review.googlesource.com/582487
Commit-Queue: Caitlin Potter <caitp@igalia.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@{#47224}
This code appears to have been wrong forever, as it only
threw in strict mode (presumably predating ES2015 const).
In order to get exactly the right behavior, special
handling of sloppy named function expressions is required.
Rather than polluting PropertyAttributes with another
dummy value, this CL simply adds a bool output argument
to Context::Lookup to indicate that case.
Bug: v8:6677
Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b
Reviewed-on: https://chromium-review.googlesource.com/602690
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47207}
Some bailout reasons are never referenced. Removing these allows us to
decrease the size of bailout reason bit-fields to 7 bits.
Change-Id: Ib5e884d224c12313e06493ed05a18a22b3951665
Reviewed-on: https://chromium-review.googlesource.com/596128
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47077}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.orgTBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
The patch changes CallPrinter's AST traversal to continue even after
the first positive match for an AST node. This helps us check for the
subsequent GetIterator AST node in case of destructuring.
We can not differentiate between the function call failing and the
GetIterator failing based on source position info. This would involve
runtime checks costing performance.
Instead of providing an incorrect error, we provide both the
possiblities to user and allow them to disambiguate.
Previously,
d8> function f() { return 5; }
undefined
d8> var [a] = f();
(d8):1: TypeError: f is not a function
var [a] = f();
^
TypeError: f is not a function
at (d8):1:11
Now,
d8> function f() { return 5; }
undefined
d8> var [a] = f();
(d8):1: TypeError: f is not a function or its return value is not iterable
var [a] = f();
^
TypeError: f is not a function or its return value is not iterable
at (d8):1:11
Bug: v8:6616, v8:6513
Change-Id: I3d6427f10cae54951b0ad0e5ddcbe802bb7191c1
Reviewed-on: https://chromium-review.googlesource.com/594894
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47025}
This reverts commit 409f84c93b.
Reason for revert: Breaks nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288
Original change's description:
> [async-iteration] implement spec-change to `yield` in async generators
>
> Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
>
> AsyncGeneratorResolve no longer unwraps a value component. Instead, the
> value is unwrapped before the builtin call via Await, allowing Promise
> rejections to affect the generator control flow.
>
> Thus, all `yield <expr>` implicitly become `yield await <expr>`.
>
> Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
> the generator is resumed with `.return()`, the parameter passed to .return()
> is awaited before generator execution properly continues).
>
> BUG=v8:5855
> R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
> Reviewed-on: https://chromium-review.googlesource.com/523844
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47011}
TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com
Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5855
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593952
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47013}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the
value is unwrapped before the builtin call via Await, allowing Promise
rejections to affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
the generator is resumed with `.return()`, the parameter passed to .return()
is awaited before generator execution properly continues).
BUG=v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
Reviewed-on: https://chromium-review.googlesource.com/523844
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47011}
Instead of having feedback vector as a subtype of FixedArray with
reserved slots, make it a first-class variable-sized object with a
fixed-size header. This allows us to compress counters to ints in the
header, rather than forcing them to be Smis.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48
Reviewed-on: https://chromium-review.googlesource.com/585129
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46935}
Before we try to do ASI and fail with a generic error, we special case
for the await token in the failure case.
Bug: v8:6572, v8:6513
Change-Id: Ia050c98b5a5b20bc326f429a367635b8553e4112
Reviewed-on: https://chromium-review.googlesource.com/582210
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46885}
Remove need for shuffling of accumulator and operand registers when
suspending a generator
BUG=v8:6351
TBR=bmeurer@chromium.org
Change-Id: I372509adc03b9781716412b809639554fe16e372
Reviewed-on: https://chromium-review.googlesource.com/578377
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46883}
Bug: chromium:740591
Change-Id: I869be41d8630b23704b9470c4d3db8a21bbde873
Reviewed-on: https://chromium-review.googlesource.com/583531
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46881}
Reland of https://chromium-review.googlesource.com/c/544888/.
Instead of counting profiler ticks on the shared function info (which is
shared between native contexts), count them on the feedback vector
(which is not). This allows us to continue pushing optimization
decisions off the SFI, onto the feedback vector.
Note that a side-effect of this is that ICs don't have to walk the stack
to reset profiler ticks, as they can access the feedback vector directly
from their feedback nexus.
Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48
Reviewed-on: https://chromium-review.googlesource.com/579051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46868}
Simplify the model for generating Awaits, because the resume point is
always immediately following the suspend point, and registers used are
always the same for both operations.
Includes a minor refactoring of BytecodeGenerator::VisitYield() to
perform iterator result creation before the SuspendGenerator bytecode,
rather than between SuspendGenerator and Return. This adds a small
number of bytecodes for each yield.
BUG=v8:2355, v8:5855
Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089
Reviewed-on: https://chromium-review.googlesource.com/576286
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46820}
This reverts commit a2fcdc7cc8.
Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
Original change's description:
> [runtime] Move profiler ticks from SFI to feedback vector
>
> Instead of counting profiler ticks on the shared function info (which is
> shared between native contexts), count them on the feedback vector
> (which is not). This allows us to continue pushing optimization
> decisions off the SFI, onto the feedback vector.
>
> Note that a side-effect of this is that ICs don't have to walk the stack
> to reset profiler ticks, as they can access the feedback vector directly
> from their feedback nexus.
>
> Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
> Reviewed-on: https://chromium-review.googlesource.com/544888
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46411}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
Reviewed-on: https://chromium-review.googlesource.com/574227
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46702}
SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.
As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:
- Modification of MacroAssembler AssertGeneratorObject. No longer
accepts a SuspendFlags parameter to determine which type of check to
perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
AccessBuilders associated with the [[await_input_or_debug_pos]] field
in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
prevent the need for the other SuspendFlag values.
BUG=v8:5855
TBR=bmeurer@chromium.org
Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
