AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
44c24bf827
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.

726 lines
26 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
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
bytecode array length: 189
[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: [
[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(SwitchOnGeneratorState), R(0), U8(0), U8(2),
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),
[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(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),
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),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(95),
[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(LdaUndefined),
[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(Mov), R(0), R(5),
Revert promises optimizations due to regressions in async hooks Revert "[async-await] Eliminate throwaway promise in async functions." This reverts commit a840f1f8f7e6c9ab32dec456a954612619855093. Revert "[async-generators] Also avoid throwaway promise here." This reverts commit feb545ceba5cb477ba883b46b60142f441ad5a3d. Revert "[async-await] Turn await closures into intrinsics." This reverts commit d97bb317386506a6798386b74647cbe0502fce35. Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield." This reverts commit e57b500eb26dc595609613963468910eb4bcae2e. Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve." This reverts commit c15802e11e30976528d1b711a9b9e6ff6b490117. Revert "[promises] Correctly run before/after hooks for await." This reverts commit ca7639239fc13e992e857710cbf7dbaac87163bf. Bug: v8:7253, v8:7745 Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89 Reviewed-on: https://chromium-review.googlesource.com/1049975 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 08:55:07 +00:00
B(CallJSRuntime), U8(%async_generator_await_uncaught), R(5), 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(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),
[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),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(LdaZero),
[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),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(JumpIfTrue), 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(Ldar), R(5),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +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(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),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(52),
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),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(CreateCatchContext), R(5), 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(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),
[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(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] 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(LdaSmi), I8(1),
B(Star), R(1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(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
B(LdaSmi), I8(-1),
[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] 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(Jump), U8(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(Star), R(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(LdaSmi), I8(2),
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),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(SwitchOnSmiNoFeedback), U8(5), 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),
[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),
[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
B(ReThrow),
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],
Smi [70],
[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 [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
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],
[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 [20],
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: [
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
[20, 134, 142],
[ignition] Reduce generator switch boilerplate The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 11:19:51 +00:00
[23, 98, 100],
[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
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
bytecode array length: 233
[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: [
[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(SwitchOnGeneratorState), R(0), U8(0), U8(3),
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),
[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(SwitchOnSmiNoFeedback), U8(3), 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),
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),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(139),
[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),
[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(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
/* 22 E> */ B(Throw),
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),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(95),
[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(LdaUndefined),
[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(Mov), R(0), R(5),
Revert promises optimizations due to regressions in async hooks Revert "[async-await] Eliminate throwaway promise in async functions." This reverts commit a840f1f8f7e6c9ab32dec456a954612619855093. Revert "[async-generators] Also avoid throwaway promise here." This reverts commit feb545ceba5cb477ba883b46b60142f441ad5a3d. Revert "[async-await] Turn await closures into intrinsics." This reverts commit d97bb317386506a6798386b74647cbe0502fce35. Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield." This reverts commit e57b500eb26dc595609613963468910eb4bcae2e. Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve." This reverts commit c15802e11e30976528d1b711a9b9e6ff6b490117. Revert "[promises] Correctly run before/after hooks for await." This reverts commit ca7639239fc13e992e857710cbf7dbaac87163bf. Bug: v8:7253, v8:7745 Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89 Reviewed-on: https://chromium-review.googlesource.com/1049975 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 08:55:07 +00:00
B(CallJSRuntime), U8(%async_generator_await_uncaught), R(5), 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(SuspendGenerator), R(0), R(0), U8(5), U8(2),
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),
[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),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(LdaZero),
[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),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(JumpIfTrue), 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(Ldar), R(5),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +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(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),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(52),
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),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(CreateCatchContext), R(5), 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(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),
[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(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] 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(LdaSmi), I8(1),
B(Star), R(1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(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
B(LdaSmi), I8(-1),
[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] 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(Jump), U8(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(Star), R(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(LdaSmi), I8(2),
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),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(SwitchOnSmiNoFeedback), U8(8), 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),
[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),
[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
B(ReThrow),
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],
Smi [74],
Smi [114],
[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 [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
Smi [7],
[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 [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
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],
[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 [20],
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: [
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
[20, 178, 186],
[ignition] Reduce generator switch boilerplate The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 11:19:51 +00:00
[23, 142, 144],
[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] 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: 22
[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
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
bytecode array length: 490
[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: [
[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(SwitchOnGeneratorState), R(2), U8(0), U8(3),
B(Mov), R(closure), R(11),
B(Mov), R(this), R(12),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(11), 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(2),
/* 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(13),
[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(Mov), R(context), R(14),
[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(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
/* 17 E> */ B(SuspendGenerator), R(2), R(0), U8(15), U8(0),
B(ResumeGenerator), R(2), R(0), U8(15),
B(Star), R(15),
[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(2), U8(1),
[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(SwitchOnSmiNoFeedback), U8(3), 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(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
/* 17 E> */ B(Throw),
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(11),
B(Mov), R(15), R(12),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(JumpConstant), U8(18),
[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(LdaZero),
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(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(Mov), R(context), R(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
B(Mov), R(context), R(18),
[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
/* 36 S> */ B(CreateArrayLiteral), U8(5), U8(0), U8(37),
[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(19),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(LdaNamedProperty), R(19), U8(6), U8(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(Star), R(20),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(CallProperty0), R(20), R(19), 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
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(4),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
/* 36 E> */ B(LdaNamedProperty), R(4), U8(7), 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(5),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
/* 31 S> */ B(CallProperty0), R(5), R(4), U8(7),
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(6),
/* 31 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(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(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
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(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(1),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(LdaNamedProperty), R(6), U8(8), U8(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(JumpIfToBooleanTrue), U8(68),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(LdaNamedProperty), R(6), U8(9), U8(11),
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),
Revert "[esnext] load `iterator.next` only once at beginning of iteration" This reverts commit bf4cc9ee154f15942594016777f77d3208230f5f. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265 Original change's description: > [esnext] load `iterator.next` only once at beginning of iteration > > https://github.com/tc39/ecma262/pull/988 gained concensus during the > september 2017 TC39 meetings. This moves the load of the "next" method > to the very beginning of the iteration protocol, rather than during > each iteration step. > > This impacts: > > - yield* > - for-of loops > - spread arguments > - array spreads > > In the v8 implementation, this also affects async iteration versions of > these things (the sole exception being the Async-From-Sync iterator, > which requires a few more changes to work with this, likely done in a > followup patch). > > This change introduces a new AST node, ResolvedProperty, which can be used > as a callee by Call nodes to produce the same bytecode as Property calls, > without observably re-loading the property. This is used in several > AST-desugarings involving the iteration protocol. > > BUG=v8:6861, v8:5699 > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b > Reviewed-on: https://chromium-review.googlesource.com/687997 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50452} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6861, v8:5699 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/857616 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
2018-01-09 16:50:16 +00:00
B(LdaSmi), I8(2),
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(7),
B(Mov), R(8), 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
/* 22 E> */ B(StackCheck),
B(Mov), R(3), R(0),
[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] 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(21),
B(Mov), R(2), R(19),
B(Mov), R(0), R(20),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorYield), R(19), U8(3),
/* 42 E> */ B(SuspendGenerator), R(2), R(0), U8(19), U8(1),
B(ResumeGenerator), R(2), R(0), U8(19),
B(Star), R(19),
[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(2), 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(SwitchOnSmiNoFeedback), U8(10), U8(2), I8(0),
B(Ldar), R(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
/* 42 E> */ B(Throw),
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(15),
B(Mov), R(19), R(16),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(59),
[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(LdaZero),
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(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(JumpLoop), U8(87), I8(0),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(37),
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(19),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(CreateCatchContext), R(19), U8(12),
[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(18),
[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(18),
B(PushContext), R(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
B(LdaSmi), I8(2),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(TestEqualStrict), R(7), U8(13),
[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(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
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(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(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(20),
B(CallRuntime), U16(Runtime::kReThrow), R(20), U8(1),
B(PopContext), R(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
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(16),
[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(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
B(Jump), U8(8),
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(16),
[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(LdaSmi), I8(1),
B(Star), 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
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(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
B(LdaZero),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(TestEqualStrict), R(7), U8(14),
[ESNext] Implement optional catch binding This is just a rebased version of https://chromium-review.googlesource.com/c/v8/v8/+/571453 with no functional changes Bug: v8:6889 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765 Reviewed-on: https://chromium-review.googlesource.com/849423 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50417}
2018-01-04 19:15:04 +00:00
B(JumpIfTrue), U8(90),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(LdaNamedProperty), R(4), U8(13), U8(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(Star), R(9),
[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(TestUndetectable),
B(JumpIfFalse), U8(4),
[ESNext] Implement optional catch binding This is just a rebased version of https://chromium-review.googlesource.com/c/v8/v8/+/571453 with no functional changes Bug: v8:6889 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765 Reviewed-on: https://chromium-review.googlesource.com/849423 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50417}
2018-01-04 19:15:04 +00:00
B(Jump), U8(79),
[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),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
B(TestEqualStrict), R(7), U8(17),
[ESNext] Implement optional catch binding This is just a rebased version of https://chromium-review.googlesource.com/c/v8/v8/+/571453 with no functional changes Bug: v8:6889 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765 Reviewed-on: https://chromium-review.googlesource.com/849423 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50417}
2018-01-04 19:15:04 +00:00
B(JumpIfFalse), U8(47),
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(Ldar), R(9),
[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),
[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(JumpIfFalse), U8(4),
B(Jump), U8(18),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Wide), B(LdaSmi), I16(154),
[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(18),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(LdaConstant), U8(14),
Revert "[esnext] load `iterator.next` only once at beginning of iteration" This reverts commit bf4cc9ee154f15942594016777f77d3208230f5f. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265 Original change's description: > [esnext] load `iterator.next` only once at beginning of iteration > > https://github.com/tc39/ecma262/pull/988 gained concensus during the > september 2017 TC39 meetings. This moves the load of the "next" method > to the very beginning of the iteration protocol, rather than during > each iteration step. > > This impacts: > > - yield* > - for-of loops > - spread arguments > - array spreads > > In the v8 implementation, this also affects async iteration versions of > these things (the sole exception being the Async-From-Sync iterator, > which requires a few more changes to work with this, likely done in a > followup patch). > > This change introduces a new AST node, ResolvedProperty, which can be used > as a callee by Call nodes to produce the same bytecode as Property calls, > without observably re-loading the property. This is used in several > AST-desugarings involving the iteration protocol. > > BUG=v8:6861, v8:5699 > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b > Reviewed-on: https://chromium-review.googlesource.com/687997 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50452} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6861, v8:5699 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/857616 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
2018-01-09 16:50:16 +00:00
B(Star), R(19),
[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::kNewTypeError), R(18), 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] 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(18),
B(Mov), R(9), R(19),
B(Mov), R(4), R(20),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(19), U8(2),
[ESNext] Implement optional catch binding This is just a rebased version of https://chromium-review.googlesource.com/c/v8/v8/+/571453 with no functional changes Bug: v8:6889 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765 Reviewed-on: https://chromium-review.googlesource.com/849423 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50417}
2018-01-04 19:15:04 +00:00
B(Jump), U8(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(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(18),
[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(Jump), U8(27),
[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(9), R(18),
B(Mov), R(4), R(19),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(18), U8(2),
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(10),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(10), U8(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(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
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(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), 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(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
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(15),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(SwitchOnSmiNoFeedback), U8(15), U8(2), 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(Jump), U8(13),
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(11),
B(Mov), R(16), R(12),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(98),
[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(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
B(ReThrow),
B(LdaUndefined),
Revert "[esnext] load `iterator.next` only once at beginning of iteration" This reverts commit bf4cc9ee154f15942594016777f77d3208230f5f. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265 Original change's description: > [esnext] load `iterator.next` only once at beginning of iteration > > https://github.com/tc39/ecma262/pull/988 gained concensus during the > september 2017 TC39 meetings. This moves the load of the "next" method > to the very beginning of the iteration protocol, rather than during > each iteration step. > > This impacts: > > - yield* > - for-of loops > - spread arguments > - array spreads > > In the v8 implementation, this also affects async iteration versions of > these things (the sole exception being the Async-From-Sync iterator, > which requires a few more changes to work with this, likely done in a > followup patch). > > This change introduces a new AST node, ResolvedProperty, which can be used > as a callee by Call nodes to produce the same bytecode as Property calls, > without observably re-loading the property. This is used in several > AST-desugarings involving the iteration protocol. > > BUG=v8:6861, v8:5699 > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b > Reviewed-on: https://chromium-review.googlesource.com/687997 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50452} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6861, v8:5699 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/857616 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
2018-01-09 16:50:16 +00:00
B(Star), R(16),
[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(2), R(15),
Revert promises optimizations due to regressions in async hooks Revert "[async-await] Eliminate throwaway promise in async functions." This reverts commit a840f1f8f7e6c9ab32dec456a954612619855093. Revert "[async-generators] Also avoid throwaway promise here." This reverts commit feb545ceba5cb477ba883b46b60142f441ad5a3d. Revert "[async-await] Turn await closures into intrinsics." This reverts commit d97bb317386506a6798386b74647cbe0502fce35. Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield." This reverts commit e57b500eb26dc595609613963468910eb4bcae2e. Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve." This reverts commit c15802e11e30976528d1b711a9b9e6ff6b490117. Revert "[promises] Correctly run before/after hooks for await." This reverts commit ca7639239fc13e992e857710cbf7dbaac87163bf. Bug: v8:7253, v8:7745 Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89 Reviewed-on: https://chromium-review.googlesource.com/1049975 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 08:55:07 +00:00
B(CallJSRuntime), U8(%async_generator_await_uncaught), R(15), 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(SuspendGenerator), R(2), R(0), U8(15), U8(2),
B(ResumeGenerator), R(2), R(0), U8(15),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), 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(16),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(LdaZero),
[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(16),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(JumpIfTrue), 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(Ldar), R(15),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +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(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(11),
B(Mov), R(15), R(12),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(52),
B(Jump), U8(36),
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(15),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(CreateCatchContext), R(15), 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(14),
[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(14),
B(PushContext), 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
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(17),
B(Mov), R(2), R(16),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorReject), R(16), U8(2),
B(PopContext), 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(Star), R(12),
[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(LdaSmi), I8(1),
B(Star), R(11),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(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
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(12),
[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),
[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(Jump), U8(8),
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(12),
[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(LdaSmi), I8(2),
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] 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(13),
[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(2), 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(13),
[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(11),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +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),
[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(16),
B(Mov), R(2), R(14),
B(Mov), R(12), R(15),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorResolve), R(14), 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] 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(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
/* 50 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(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),
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],
Smi [154],
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
Smi [371],
[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 [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
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
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
[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 [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
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
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Smi [6],
Smi [14],
[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,
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
Smi [396],
[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],
[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 [20],
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: [
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
[20, 435, 443],
[23, 399, 401],
[61, 222, 230],
[ignition] Reduce generator switch boilerplate The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 11:19:51 +00:00
[64, 185, 187],
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
[291, 301, 303],
[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] 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: 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
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
bytecode array length: 479
[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: [
[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(SwitchOnGeneratorState), R(0), U8(0), U8(5),
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),
[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(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),
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),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(JumpConstant), U8(18),
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
/* 49 S> */ B(LdaGlobal), U8(7), U8(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(Star), R(12),
/* 56 E> */ B(CallUndefinedReceiver0), R(12), U8(2),
B(Star), R(10),
B(LdaNamedProperty), R(10), U8(8), U8(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(JumpIfUndefined), U8(17),
B(JumpIfNull), 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),
[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(JumpIfJSReceiver), U8(23),
B(CallRuntime), U16(Runtime::kThrowSymbolAsyncIteratorInvalid), R(0), U8(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(LdaNamedProperty), R(10), U8(9), U8(8),
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),
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),
B(SwitchOnSmiNoFeedback), U8(11), U8(2), I8(1),
B(CallProperty1), R(9), R(7), R(8), U8(14),
B(Jump), U8(110),
B(LdaNamedProperty), R(7), U8(13), U8(16),
[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(JumpIfUndefined), U8(13),
B(JumpIfNull), U8(11),
[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(12),
B(CallProperty1), R(12), R(7), R(8), U8(18),
B(Jump), U8(93),
[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(1),
B(Mov), R(8), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(JumpConstant), U8(19),
[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(LdaNamedProperty), R(7), U8(14), U8(20),
[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(JumpIfUndefined), U8(13),
B(JumpIfNull), U8(11),
[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(12),
B(CallProperty1), R(12), R(7), R(8), U8(22),
B(Jump), U8(68),
B(LdaNamedProperty), R(7), U8(13), U8(24),
B(JumpIfUndefined), U8(57),
B(JumpIfNull), U8(55),
B(Star), R(12),
B(CallProperty0), R(12), R(7), U8(26),
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(Jump), U8(2),
[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(13),
[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(0), R(12),
Revert promises optimizations due to regressions in async hooks Revert "[async-await] Eliminate throwaway promise in async functions." This reverts commit a840f1f8f7e6c9ab32dec456a954612619855093. Revert "[async-generators] Also avoid throwaway promise here." This reverts commit feb545ceba5cb477ba883b46b60142f441ad5a3d. Revert "[async-await] Turn await closures into intrinsics." This reverts commit d97bb317386506a6798386b74647cbe0502fce35. Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield." This reverts commit e57b500eb26dc595609613963468910eb4bcae2e. Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve." This reverts commit c15802e11e30976528d1b711a9b9e6ff6b490117. Revert "[promises] Correctly run before/after hooks for await." This reverts commit ca7639239fc13e992e857710cbf7dbaac87163bf. Bug: v8:7253, v8:7745 Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89 Reviewed-on: https://chromium-review.googlesource.com/1049975 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 08:55:07 +00:00
B(CallJSRuntime), U8(%async_generator_await_uncaught), R(12), U8(2),
[ignition] Move suspend_id assignment to bytecode generation Instead of building suspend_ids in the AST numbering, collect suspend counts in the parser and assigning suspend ids during bytecode generation. Bug: v8:7178 Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0 Reviewed-on: https://chromium-review.googlesource.com/817598 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50830}
2018-01-24 11:16:52 +00:00
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(12), 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(ResumeGenerator), R(0), R(0), U8(12),
B(Star), R(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(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(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] 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(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] 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(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] 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(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(JumpIfJSReceiver), U8(9),
B(Star), R(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(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(14), U8(1),
B(CallRuntime), U16(Runtime::kThrowThrowMethodMissing), R(0), U8(0),
Revert "[esnext] load `iterator.next` only once at beginning of iteration" This reverts commit bf4cc9ee154f15942594016777f77d3208230f5f. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265 Original change's description: > [esnext] load `iterator.next` only once at beginning of iteration > > https://github.com/tc39/ecma262/pull/988 gained concensus during the > september 2017 TC39 meetings. This moves the load of the "next" method > to the very beginning of the iteration protocol, rather than during > each iteration step. > > This impacts: > > - yield* > - for-of loops > - spread arguments > - array spreads > > In the v8 implementation, this also affects async iteration versions of > these things (the sole exception being the Async-From-Sync iterator, > which requires a few more changes to work with this, likely done in a > followup patch). > > This change introduces a new AST node, ResolvedProperty, which can be used > as a callee by Call nodes to produce the same bytecode as Property calls, > without observably re-loading the property. This is used in several > AST-desugarings involving the iteration protocol. > > BUG=v8:6861, v8:5699 > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b > Reviewed-on: https://chromium-review.googlesource.com/687997 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50452} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6861, v8:5699 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/857616 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
2018-01-09 16:50:16 +00:00
B(Star), R(13),
[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(0), R(12),
Revert promises optimizations due to regressions in async hooks Revert "[async-await] Eliminate throwaway promise in async functions." This reverts commit a840f1f8f7e6c9ab32dec456a954612619855093. Revert "[async-generators] Also avoid throwaway promise here." This reverts commit feb545ceba5cb477ba883b46b60142f441ad5a3d. Revert "[async-await] Turn await closures into intrinsics." This reverts commit d97bb317386506a6798386b74647cbe0502fce35. Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield." This reverts commit e57b500eb26dc595609613963468910eb4bcae2e. Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve." This reverts commit c15802e11e30976528d1b711a9b9e6ff6b490117. Revert "[promises] Correctly run before/after hooks for await." This reverts commit ca7639239fc13e992e857710cbf7dbaac87163bf. Bug: v8:7253, v8:7745 Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89 Reviewed-on: https://chromium-review.googlesource.com/1049975 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 08:55:07 +00:00
B(CallJSRuntime), U8(%async_generator_await_uncaught), R(12), U8(2),
[ignition] Move suspend_id assignment to bytecode generation Instead of building suspend_ids in the AST numbering, collect suspend counts in the parser and assigning suspend ids during bytecode generation. Bug: v8:7178 Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0 Reviewed-on: https://chromium-review.googlesource.com/817598 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50830}
2018-01-24 11:16:52 +00:00
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(12), 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(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] 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(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] 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(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] 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(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] 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(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),
B(LdaNamedProperty), R(5), U8(15), U8(28),
B(JumpIfToBooleanTrue), U8(38),
B(LdaNamedProperty), R(5), U8(16), U8(30),
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] 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(16),
B(Mov), R(0), R(14),
B(InvokeIntrinsic), U8(Runtime::k_AsyncGeneratorYield), R(14), U8(3),
[ignition] Move suspend_id assignment to bytecode generation Instead of building suspend_ids in the AST numbering, collect suspend counts in the parser and assigning suspend ids during bytecode generation. Bug: v8:7178 Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0 Reviewed-on: https://chromium-review.googlesource.com/817598 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50830}
2018-01-24 11:16:52 +00:00
/* 49 E> */ B(SuspendGenerator), R(0), R(0), U8(14), 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(ResumeGenerator), R(0), R(0), U8(14),
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),
B(JumpLoop), U8(206), I8(0),
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] 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(JumpIfFalse), U8(10),
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),
B(Mov), R(7), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(95),
[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(LdaUndefined),
[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(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(Mov), R(0), R(5),
Revert promises optimizations due to regressions in async hooks Revert "[async-await] Eliminate throwaway promise in async functions." This reverts commit a840f1f8f7e6c9ab32dec456a954612619855093. Revert "[async-generators] Also avoid throwaway promise here." This reverts commit feb545ceba5cb477ba883b46b60142f441ad5a3d. Revert "[async-await] Turn await closures into intrinsics." This reverts commit d97bb317386506a6798386b74647cbe0502fce35. Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield." This reverts commit e57b500eb26dc595609613963468910eb4bcae2e. Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve." This reverts commit c15802e11e30976528d1b711a9b9e6ff6b490117. Revert "[promises] Correctly run before/after hooks for await." This reverts commit ca7639239fc13e992e857710cbf7dbaac87163bf. Bug: v8:7253, v8:7745 Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89 Reviewed-on: https://chromium-review.googlesource.com/1049975 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 08:55:07 +00:00
B(CallJSRuntime), U8(%async_generator_await_uncaught), R(5), 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(SuspendGenerator), R(0), R(0), U8(5), U8(4),
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),
[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),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(LdaZero),
[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),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(JumpIfTrue), 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(Ldar), R(5),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(ReThrow),
[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(1),
B(Mov), R(5), R(2),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(Jump), U8(52),
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),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +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),
[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(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] 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(LdaSmi), I8(1),
B(Star), R(1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(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
B(LdaSmi), I8(-1),
[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] 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(Jump), U8(8),
[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] 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(LdaSmi), I8(2),
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),
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
B(SwitchOnSmiNoFeedback), U8(20), 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),
[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),
[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
B(ReThrow),
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],
Smi [201],
Smi [251],
[ignition] Move suspend_id assignment to bytecode generation Instead of building suspend_ids in the AST numbering, collect suspend counts in the parser and assigning suspend ids during bytecode generation. Bug: v8:7178 Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0 Reviewed-on: https://chromium-review.googlesource.com/817598 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50830}
2018-01-24 11:16:52 +00:00
Smi [310],
[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 [360],
[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 [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
Smi [7],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["g"],
SYMBOL_TYPE,
SYMBOL_TYPE,
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],
Smi [36],
[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,
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
Smi [385],
Smi [286],
[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],
[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 [20],
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: [
Remove the catch variable name from the extension field of catch contexts Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 09:29:20 +00:00
[20, 424, 432],
[ignition] Reduce generator switch boilerplate The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 11:19:51 +00:00
[23, 388, 390],
[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