AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
38301e7bb9
v8/test/cctest/interpreter/bytecode_expectations/AsyncGenerators.golden

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

623 lines
22 KiB
Plaintext
Raw Normal View History

[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
test function name: f
async iteration: yes
---
snippet: "
async function* f() { }
f();
"
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
frame size: 8
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
parameter count: 1
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
bytecode array length: 148
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
bytecodes: [
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Mov), R(closure), R(1),
B(Mov), R(this), R(2),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(1), U8(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(Star), R(0),
/* 17 E> */ B(StackCheck),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Mov), R(context), R(3),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(4),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator 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}
2017-07-25 18:37:36 +00:00
B(Ldar), R(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
/* 17 E> */ B(SuspendGenerator), R(0), R(0), U8(5), U8(0),
B(ResumeGenerator), R(0), R(0), U8(5),
B(Star), R(5),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(2), I8(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(5),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 17 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
B(Mov), R(5), R(2),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(53),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(5),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(36),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(5),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(CreateCatchContext), R(5), U8(3),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(4),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(4),
B(PushContext), R(5),
Revert "Reland "[runtime] Move Context::native_context to the map"" This reverts commit c7c47c68f2c0eb1155cfacab785aba54f61d9218. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e0df48aa6a32d958fb4339a85fefb5179 > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
2019-10-16 13:10:30 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(7),
B(Mov), R(0), R(6),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorReject), R(6), U8(2),
B(PopContext), R(5),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(2),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(2),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(15),
B(LdaSmi), I8(-1),
B(Star), R(2),
B(Star), R(1),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(2),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorClose), R(0), U8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(4), U8(3), I8(0),
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
B(Jump), U8(22),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Ldar), R(2),
B(ReThrow),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTrue),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(6),
B(Mov), R(0), R(4),
B(Mov), R(2), R(5),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorResolve), R(4), U8(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 22 S> */ B(Return),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 22 S> */ B(Return),
B(LdaUndefined),
/* 22 S> */ B(Return),
]
constant pool: [
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
Smi [30],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [16],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [7],
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_TYPE,
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [6],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [9],
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
Smi [23],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
handlers: [
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
[20, 94, 102],
[23, 56, 60],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
---
snippet: "
async function* f() { yield 42 }
f();
"
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
frame size: 8
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
parameter count: 1
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
bytecode array length: 193
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
bytecodes: [
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Mov), R(closure), R(1),
B(Mov), R(this), R(2),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(1), U8(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(Star), R(0),
/* 17 E> */ B(StackCheck),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Mov), R(context), R(3),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(4),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator 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}
2017-07-25 18:37:36 +00:00
B(Ldar), R(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
/* 17 E> */ B(SuspendGenerator), R(0), R(0), U8(5), U8(0),
B(ResumeGenerator), R(0), R(0), U8(5),
B(Star), R(5),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(5),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 17 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
B(Mov), R(5), R(2),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(98),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 22 S> */ B(LdaSmi), I8(42),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(6),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(LdaFalse),
B(Star), R(7),
B(Mov), R(0), R(5),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorYield), R(5), U8(3),
/* 22 E> */ B(SuspendGenerator), R(0), R(0), U8(5), U8(1),
B(ResumeGenerator), R(0), R(0), U8(5),
B(Star), R(5),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(4), U8(2), I8(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(5),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 22 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
B(Mov), R(5), R(2),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(53),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(5),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(36),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(5),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(CreateCatchContext), R(5), U8(6),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(4),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(4),
B(PushContext), R(5),
Revert "Reland "[runtime] Move Context::native_context to the map"" This reverts commit c7c47c68f2c0eb1155cfacab785aba54f61d9218. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e0df48aa6a32d958fb4339a85fefb5179 > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
2019-10-16 13:10:30 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(7),
B(Mov), R(0), R(6),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorReject), R(6), U8(2),
B(PopContext), R(5),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(2),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(2),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(15),
B(LdaSmi), I8(-1),
B(Star), R(2),
B(Star), R(1),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(2),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorClose), R(0), U8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(7), U8(3), I8(0),
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
B(Jump), U8(22),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Ldar), R(2),
B(ReThrow),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTrue),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(6),
B(Mov), R(0), R(4),
B(Mov), R(2), R(5),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorResolve), R(4), U8(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 31 S> */ B(Return),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 31 S> */ B(Return),
B(LdaUndefined),
/* 31 S> */ B(Return),
]
constant pool: [
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
Smi [30],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [75],
Smi [16],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [7],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [16],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [7],
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_TYPE,
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [6],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [9],
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
Smi [23],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
handlers: [
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
[20, 139, 147],
[23, 101, 105],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
---
snippet: "
async function* f() { for (let x of [42]) yield x }
f();
"
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
frame size: 19
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
parameter count: 1
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
bytecode array length: 357
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
bytecodes: [
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Mov), R(closure), R(4),
B(Mov), R(this), R(5),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(4), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(0),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 17 E> */ B(StackCheck),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Mov), R(context), R(6),
B(Mov), R(context), R(7),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Ldar), R(0),
/* 17 E> */ B(SuspendGenerator), R(0), R(0), U8(8), U8(0),
B(ResumeGenerator), R(0), R(0), U8(8),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(8),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Ldar), R(8),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 17 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(4),
B(Mov), R(8), R(5),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(JumpConstant), U8(15),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
/* 36 S> */ B(CreateArrayLiteral), U8(4), U8(0), U8(37),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(10),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(GetIterator), R(10), U8(1), U8(3),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(9),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(9), U8(5), U8(5),
Reland "[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 TBR=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}
2018-01-11 17:24:11 +00:00
B(Star), R(8),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(LdaFalse),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(10),
B(Mov), R(context), R(13),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(LdaTrue),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(10),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
/* 31 S> */ B(CallProperty0), R(8), R(9), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(14),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(JumpIfJSReceiver), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(14), U8(1),
B(LdaNamedProperty), R(14), U8(6), U8(9),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(JumpIfToBooleanTrue), U8(67),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(LdaNamedProperty), R(14), U8(7), U8(11),
B(Star), R(14),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(LdaFalse),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(10),
B(Mov), R(14), R(1),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 22 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 31 S> */ B(Mov), R(1), R(3),
[async-iteration] eliminate Suspend for AsyncGeneratorYield await A spec change (https://github.com/tc39/proposal-async-iteration/commit/a0dfeba1a8029012b6e964099929b8a157818c9f) 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}
2017-08-07 14:13:18 +00:00
/* 42 S> */ B(LdaFalse),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(17),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Mov), R(0), R(15),
B(Mov), R(3), R(16),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorYield), R(15), U8(3),
/* 42 E> */ B(SuspendGenerator), R(0), R(0), U8(15), U8(1),
B(ResumeGenerator), R(0), R(0), U8(15),
B(Star), R(15),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(SwitchOnSmiNoFeedback), U8(8), U8(2), I8(0),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(15),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 42 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(11),
B(Mov), R(15), R(12),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Jump), U8(20),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(15),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(JumpLoop), U8(84), I8(0),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaSmi), I8(-1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(12),
B(Star), R(11),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(12),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(11),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(13),
B(Ldar), R(10),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfToBooleanTrue), U8(58),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(9), U8(10), U8(13),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(15),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(50),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Mov), R(context), R(16),
[bigint] Fix typeof. 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}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(JumpIfTrue), U8(18),
[parser] Improve error when using import decl in a script Perform a best-effort check for module context and provide an appropriate error. As seen from the import-blah-script.js test, we could have invalid import expressions in a script context that could result in an error saying "Cannot use import statement outside a module" which isn't the ideal error because the error is an incorrect import expression. But, when the developer changes to a module context, the correct error is thrown. To fix this, we'd have to refactor and call ParseImportDeclaration, and then throw an appropriate error, which seems like a lot of overhead for not enough gain. Bug: v8:9392, v8:6513 Change-Id: I520ebb490fff4d95743a7c751d4095db9a35d41b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675948 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62358}
2019-06-25 11:01:33 +00:00
B(Wide), B(LdaSmi), I16(159),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(17),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaConstant), U8(11),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(18),
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(Throw),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(CallProperty0), R(15), R(9), U8(15),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(JumpIfJSReceiver), U8(21),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(17), U8(1),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Jump), U8(12),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(16),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(TestReferenceEqual), R(11),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(JumpIfTrue), U8(5),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(16),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(ReThrow),
B(Ldar), R(13),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(SetPendingMessage),
B(Ldar), R(11),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(SwitchOnSmiNoFeedback), U8(12), U8(2), I8(0),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Jump), U8(14),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(12),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(ReThrow),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(4),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Mov), R(12), R(5),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(51),
B(Jump), U8(36),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(8),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(CreateCatchContext), R(8), U8(14),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(7),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Ldar), R(7),
B(PushContext), R(8),
Revert "Reland "[runtime] Move Context::native_context to the map"" This reverts commit c7c47c68f2c0eb1155cfacab785aba54f61d9218. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e0df48aa6a32d958fb4339a85fefb5179 > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
2019-10-16 13:10:30 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(10),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(0), R(9),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorReject), R(9), U8(2),
B(PopContext), R(8),
B(Star), R(5),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(2),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(4),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(15),
B(LdaSmi), I8(-1),
B(Star), R(5),
B(Star), R(4),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(5),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(4),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(6),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorClose), R(0), U8(1),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Ldar), R(6),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(SetPendingMessage),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Ldar), R(4),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(SwitchOnSmiNoFeedback), U8(16), U8(3), I8(0),
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
B(Jump), U8(22),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Ldar), R(5),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(ReThrow),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTrue),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Star), R(9),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(0), R(7),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Mov), R(5), R(8),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorResolve), R(7), U8(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 50 S> */ B(Return),
[ignition] Move for-of desugaring to bytecode 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}
2019-01-14 14:15:52 +00:00
B(Ldar), R(5),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 50 S> */ B(Return),
B(LdaUndefined),
/* 50 S> */ B(Return),
]
constant pool: [
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
Smi [30],
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
Smi [136],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [16],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [7],
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [16],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [7],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
Revert recent ConsString-related changes We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b7011867cf2f2d50a509b03e39c54fe0e213e0. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 5758209026018a9ca573be234580077ad5974824. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0ee1921213320ecb4555e5d463406a4ab7. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
2019-04-18 09:29:49 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [6],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [9],
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_TYPE,
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
Smi [262],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [6],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [9],
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
Smi [23],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
handlers: [
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
[20, 303, 311],
[23, 267, 269],
[80, 167, 175],
[199, 232, 234],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
---
snippet: "
function* g() { yield 42 }
async function* f() { yield* g() }
f();
"
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
frame size: 17
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
parameter count: 1
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
bytecode array length: 467
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
bytecodes: [
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(5),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Mov), R(closure), R(1),
B(Mov), R(this), R(2),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(1), U8(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(Star), R(0),
/* 44 E> */ B(StackCheck),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Mov), R(context), R(3),
[ignition] desugar AsyncGenerator yield* in BytecodeGenerator 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}
2017-08-16 16:43:28 +00:00
B(Mov), R(context), R(4),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator 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}
2017-07-25 18:37:36 +00:00
B(Ldar), R(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
/* 44 E> */ B(SuspendGenerator), R(0), R(0), U8(5), U8(0),
B(ResumeGenerator), R(0), R(0), U8(5),
B(Star), R(5),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(SwitchOnSmiNoFeedback), U8(5), U8(2), I8(0),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(5),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 44 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
B(Mov), R(5), R(2),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(JumpConstant), U8(18),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
/* 49 S> */ B(LdaGlobal), U8(7), U8(0),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Star), R(9),
/* 56 E> */ B(CallUndefinedReceiver0), R(9), U8(2),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(10),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(LdaNamedProperty), R(10), U8(8), U8(4),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(15),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(11),
B(CallProperty0), R(11), R(10), U8(6),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(JumpIfJSReceiver), U8(23),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(CallRuntime), U16(Runtime::kThrowSymbolAsyncIteratorInvalid), R(0), U8(0),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(10), U8(9), U8(8),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(11),
B(CallProperty0), R(11), R(10), U8(10),
B(Star), R(11),
B(InvokeIntrinsic), U8(Runtime::k_CreateAsyncFromSyncIterator), R(11), U8(1),
B(Star), R(7),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(7), U8(10), U8(12),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(Star), R(9),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(LdaUndefined),
B(Star), R(8),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(LdaZero),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(6),
B(Ldar), R(6),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(SwitchOnSmiNoFeedback), U8(11), U8(2), I8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(CallProperty1), R(9), R(7), R(8), U8(14),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(140),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(7), U8(13), U8(16),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(11),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(10),
B(CallProperty1), R(10), R(7), R(8), U8(18),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(125),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Mov), R(0), R(10),
B(Mov), R(8), R(11),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorAwaitUncaught), R(10), U8(2),
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(10), U8(1),
B(ResumeGenerator), R(0), R(0), U8(10),
B(Star), R(10),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(11),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(TestReferenceEqual), R(11),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(JumpIfTrue), U8(5),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(10),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(ReThrow),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(LdaSmi), I8(1),
B(Star), R(1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Mov), R(10), R(2),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(241),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(7), U8(14), U8(20),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(11),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(12),
B(CallProperty1), R(12), R(7), R(8), U8(22),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(66),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(7), U8(13), U8(24),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(55),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(12),
B(CallProperty0), R(12), R(7), U8(26),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(Jump), U8(2),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(13),
B(Mov), R(0), R(12),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorAwaitUncaught), R(12), U8(2),
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(12), U8(2),
B(ResumeGenerator), R(0), R(0), U8(12),
B(Star), R(12),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(13),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(TestReferenceEqual), R(13),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(JumpIfTrue), U8(5),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(12),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(ReThrow),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(12),
[Interpreter] Await the input value of iterator.return for yield* on async generators 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}
2019-05-09 17:25:21 +00:00
B(JumpIfJSReceiver), U8(9),
B(Star), R(14),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(14), U8(1),
B(CallRuntime), U16(Runtime::kThrowThrowMethodMissing), R(0), U8(0),
B(Star), R(13),
B(Mov), R(0), R(12),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorAwaitUncaught), R(12), U8(2),
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(12), U8(3),
B(ResumeGenerator), R(0), R(0), U8(12),
B(Star), R(12),
Reland "[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 TBR=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}
2018-01-11 17:24:11 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(13),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(TestReferenceEqual), R(13),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(JumpIfTrue), U8(5),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(12),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(ReThrow),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(12),
B(Mov), R(12), R(5),
[ignition] desugar AsyncGenerator yield* in BytecodeGenerator 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}
2017-08-16 16:43:28 +00:00
B(JumpIfJSReceiver), U8(7),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(5), U8(1),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(5), U8(15), U8(28),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(JumpIfToBooleanTrue), U8(38),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(5), U8(16), U8(30),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(15),
Reland "[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 TBR=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}
2018-01-11 17:24:11 +00:00
B(LdaFalse),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(16),
B(Mov), R(0), R(14),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorYield), R(14), U8(3),
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(14), U8(4),
B(ResumeGenerator), R(0), R(0), U8(14),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(8),
[Interpreter] Remove new.target from fixed frame slot. 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}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(6),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpLoop), U8(236), I8(0),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(LdaNamedProperty), R(5), U8(16), U8(32),
[ignition] desugar AsyncGenerator yield* in BytecodeGenerator 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}
2017-08-16 16:43:28 +00:00
B(Star), R(7),
B(LdaSmi), I8(1),
[ignition] Optimizing Smi only comparisons There are various situations where we explicitly compare a SMI against another SMI (e.g., BuildIndexedJump). This is also a common pattern for generated code (e.g., comparing a loop variable with an integer). Instead of using the generic equality/strict-equality stub for this, which is expensive, this CL offers a simple comparison stub, repurposing the TestEqualStrictNoFeedback bytecode to TestReferenceEqual Bug: v8:5310 Change-Id: Ib2b47cd24d5386cf0d20d3bd794776dc6e3a02a5 Reviewed-on: https://chromium-review.googlesource.com/1007542 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Christian O. Andersson <cricke@chromium.org> Cr-Commit-Position: refs/heads/master@{#52655}
2018-04-18 00:04:34 +00:00
B(TestReferenceEqual), R(6),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(JumpIfFalse), U8(11),
B(LdaSmi), I8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
B(Mov), R(7), R(2),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(53),
B(Ldar), R(7),
B(Jump), U8(36),
[ignition] desugar AsyncGenerator yield* in BytecodeGenerator 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}
2017-08-16 16:43:28 +00:00
B(Star), R(5),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(CreateCatchContext), R(5), U8(17),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(4),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(4),
B(PushContext), R(5),
Revert "Reland "[runtime] Move Context::native_context to the map"" This reverts commit c7c47c68f2c0eb1155cfacab785aba54f61d9218. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e0df48aa6a32d958fb4339a85fefb5179 > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
2019-10-16 13:10:30 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(7),
B(Mov), R(0), R(6),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorReject), R(6), U8(2),
B(PopContext), R(5),
[ignition] desugar AsyncGenerator yield* in BytecodeGenerator 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}
2017-08-16 16:43:28 +00:00
B(Star), R(2),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(2),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
[parser] Fix async generator bytecode to only await on explicit return Per ECMA-262 25.5.3.2, step 5.e: |generatorBody| execution ends with a normal completion. Bug: v8:9050 Change-Id: If2ecc7d104e0b905a4b2b4695522be740e0d0349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611011 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@google.com> Cr-Commit-Position: refs/heads/master@{#61589}
2019-05-15 19:41:48 +00:00
B(Jump), U8(15),
B(LdaSmi), I8(-1),
B(Star), R(2),
B(Star), R(1),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[ignition] desugar AsyncGenerator yield* in BytecodeGenerator 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}
2017-08-16 16:43:28 +00:00
B(Star), R(2),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(1),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorClose), R(0), U8(1),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(SetPendingMessage),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(1),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(SwitchOnSmiNoFeedback), U8(19), U8(3), I8(0),
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
B(Jump), U8(22),
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
B(Ldar), R(2),
B(ReThrow),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
B(LdaTrue),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Star), R(6),
B(Mov), R(0), R(4),
B(Mov), R(2), R(5),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorResolve), R(4), U8(3),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 60 S> */ B(Return),
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
B(Ldar), R(2),
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
/* 60 S> */ B(Return),
B(LdaUndefined),
/* 60 S> */ B(Return),
]
constant pool: [
[ignition] Single-switch generator bytecode 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}
2018-01-23 13:51:38 +00:00
Smi [30],
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
Smi [158],
Smi [230],
Smi [280],
Smi [339],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [16],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [7],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["g"],
SYMBOL_TYPE,
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
SYMBOL_TYPE,
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
Reland "[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 TBR=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}
2018-01-11 17:24:11 +00:00
Smi [11],
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
Smi [70],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["throw"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_TYPE,
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
Smi [372],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
Smi [6],
[ignition] Move destructuring assignments to bytecode generation 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}
2019-01-02 16:12:54 +00:00
Smi [9],
[async-iteration] eliminate implicit Await when resuming with .return() 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}
2017-08-09 13:43:29 +00:00
Smi [23],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
handlers: [
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
[20, 413, 421],
[23, 375, 379],
[cctest] add Async Generator bytecode tests These were originally written as part of https://chromium-review.googlesource.com/c/550396/. I've separated them out into a separate CL with the intent of landing it first, so that it's easier to see the difference these CLs will have on generated bytecode. BUG=v8:5855 TBR=tebbi@chromium.org, rmcilroy@chromium.org Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1 Reviewed-on: https://chromium-review.googlesource.com/558221 Reviewed-by: Caitlin Potter <caitp@igalia.com> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46370}
2017-07-02 20:59:29 +00:00
]
Reference in New Issue Copy Permalink