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

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

344 lines
12 KiB
Plaintext
Raw Normal View History

First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
test function name: f
---
snippet: "
function* f() { }
[Interpreter] Make lazy compilation the default. BUG=v8:4280,v8:5038 LOG=N Review-Url: https://codereview.chromium.org/2007453002 Cr-Commit-Position: refs/heads/master@{#36476}
2016-05-24 12:51:18 +00:00
f();
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
"
[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: 3
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
parameter count: 1
[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
bytecode array length: 44
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +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(1),
B(Mov), R(closure), R(1),
B(Mov), R(this), R(2),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(1), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(0),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 11 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
/* 11 E> */ B(SuspendGenerator), R(0), R(0), U8(1), U8(0),
B(ResumeGenerator), R(0), R(0), U8(1),
B(Star), R(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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(2), I8(0),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ 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(Ldar), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 16 S> */ B(Return),
B(LdaUndefined),
/* 16 S> */ B(Return),
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
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 [22],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
handlers: [
]
---
snippet: "
function* f() { yield 42 }
[Interpreter] Make lazy compilation the default. BUG=v8:4280,v8:5038 LOG=N Review-Url: https://codereview.chromium.org/2007453002 Cr-Commit-Position: refs/heads/master@{#36476}
2016-05-24 12:51:18 +00:00
f();
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
"
[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: 3
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
parameter count: 1
[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
bytecode array length: 80
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +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),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(0),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 11 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
/* 11 E> */ B(SuspendGenerator), R(0), R(0), U8(1), U8(0),
B(ResumeGenerator), R(0), R(0), U8(1),
B(Star), R(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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +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(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ 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(Ldar), R(1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 25 S> */ B(Return),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 16 S> */ B(LdaSmi), I8(42),
[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),
[interpreter] refactor BuildGeneratorSuspend/Resume into BuildSuspendPoint Simplify the model for generating Awaits, because the resume point is always immediately following the suspend point, and registers used are always the same for both operations. Includes a minor refactoring of BytecodeGenerator::VisitYield() to perform iterator result creation before the SuspendGenerator bytecode, rather than between SuspendGenerator and Return. This adds a small number of bytecodes for each yield. BUG=v8:2355, v8:5855 Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089 Reviewed-on: https://chromium-review.googlesource.com/576286 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46820}
2017-07-20 12:35:28 +00:00
B(LdaFalse),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +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(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(1), U8(2),
/* 16 E> */ B(SuspendGenerator), R(0), R(0), U8(1), U8(1),
B(ResumeGenerator), R(0), R(0), U8(1),
B(Star), R(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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(4), U8(2), I8(0),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 16 E> */ 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(Ldar), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 25 S> */ B(Return),
B(LdaUndefined),
/* 25 S> */ B(Return),
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
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 [22],
Smi [58],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
handlers: [
]
---
snippet: "
function* f() { for (let x of [42]) yield x }
[Interpreter] Make lazy compilation the default. BUG=v8:4280,v8:5038 LOG=N Review-Url: https://codereview.chromium.org/2007453002 Cr-Commit-Position: refs/heads/master@{#36476}
2016-05-24 12:51:18 +00:00
f();
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
"
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
frame size: 16
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
parameter count: 1
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
bytecode array length: 261
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
bytecodes: [
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(SwitchOnGeneratorState), R(2), U8(0), U8(2),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Mov), R(closure), R(4),
B(Mov), R(this), R(5),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(4), U8(2),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(Star), R(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 11 E> */ B(StackCheck),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
/* 11 E> */ B(SuspendGenerator), R(2), R(0), U8(4), U8(0),
B(ResumeGenerator), R(2), R(0), U8(4),
B(Star), R(4),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Ldar), R(4),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ B(Throw),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Ldar), R(4),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 44 S> */ B(Return),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 30 S> */ B(CreateArrayLiteral), U8(4), U8(0), U8(37),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(6),
B(LdaNamedProperty), R(6), U8(5), U8(1),
B(Star), R(7),
B(CallProperty0), R(7), R(6), U8(3),
[ignition] desugar GetIterator() via bytecode rather than via AST Introduces: - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions. - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan. The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST. This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value. BUG=v8:4280 R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org TBR=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2557593004 Cr-Commit-Position: refs/heads/master@{#41555}
2016-12-07 15:19:52 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
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),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(LdaNamedProperty), R(5), U8(6), U8(5),
B(Star), R(4),
B(LdaFalse),
Reland "[esnext] load `iterator.next` only once at beginning of iteration" https://github.com/tc39/ecma262/pull/988 gained concensus during the september 2017 TC39 meetings. This moves the load of the "next" method to the very beginning of the iteration protocol, rather than during each iteration step. This impacts: - yield* - for-of loops - spread arguments - array spreads In the v8 implementation, this also affects async iteration versions of these things (the sole exception being the Async-From-Sync iterator, which requires a few more changes to work with this, likely done in a followup patch). This change introduces a new AST node, ResolvedProperty, which can be used as a callee by Call nodes to produce the same bytecode as Property calls, without observably re-loading the property. This is used in several AST-desugarings involving the iteration protocol. BUG=v8:6861, v8:5699 R=rmcilroy@chromium.org TBR=neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b Reviewed-on: https://chromium-review.googlesource.com/857593 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50518}
2018-01-11 17:24:11 +00:00
B(Star), R(8),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Mov), R(context), R(11),
B(LdaTrue),
B(Star), R(8),
/* 25 S> */ B(CallProperty0), R(4), R(5), U8(7),
B(Star), R(12),
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(12), U8(1),
B(LdaNamedProperty), R(12), U8(7), U8(9),
B(JumpIfToBooleanTrue), U8(64),
B(LdaNamedProperty), R(12), U8(8), U8(11),
B(Star), R(12),
B(LdaFalse),
B(Star), R(8),
B(Mov), R(12), R(3),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 16 E> */ B(StackCheck),
[parser] Don't desugar destructuring declarations. Emit a single destructuring assignment for destructuring declarations, which can be desugared by the bytecode generator. This allows us to remove destructuring desugaring from the parser (specifically, the pattern rewriter) entirely. The pattern "rewriter" is now only responsible for walking the destructuring pattern to declare variables, mark them assigned, and potentially rewrite scopes for the edge case of parameters with a sloppy eval. Note that since the rewriter is no longer rewriting, we have to flip the VariableProxy copying logic for var re-lookup, so that we now pass the new VariableProxy to the variable declaration and leave the original unresolved (rather than passing the original through and rewriting to a new unresolved VariableProxy). This change does have some effect on breakpoint locations, due to some of the available information changing between the parser and bytecode generator, however the new locations appear to be more consistent between assignments and declarations. Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82 Reviewed-on: https://chromium-review.googlesource.com/c/1382462 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58670}
2019-01-09 13:21:06 +00:00
/* 25 S> */ B(Mov), R(3), R(0),
[interpreter] refactor BuildGeneratorSuspend/Resume into BuildSuspendPoint Simplify the model for generating Awaits, because the resume point is always immediately following the suspend point, and registers used are always the same for both operations. Includes a minor refactoring of BytecodeGenerator::VisitYield() to perform iterator result creation before the SuspendGenerator bytecode, rather than between SuspendGenerator and Return. This adds a small number of bytecodes for each yield. BUG=v8:2355, v8:5855 Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089 Reviewed-on: https://chromium-review.googlesource.com/576286 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46820}
2017-07-20 12:35:28 +00:00
/* 36 S> */ B(LdaFalse),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(14),
B(Mov), R(0), R(13),
B(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(13), U8(2),
/* 36 E> */ B(SuspendGenerator), R(2), R(0), U8(13), U8(1),
B(ResumeGenerator), R(2), R(0), U8(13),
B(Star), R(13),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +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(9), U8(2), I8(0),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Ldar), R(13),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 36 E> */ B(Throw),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(LdaSmi), I8(1),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(9),
B(Mov), R(13), R(10),
B(Jump), U8(20),
B(Ldar), R(13),
B(JumpLoop), U8(81), I8(0),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
B(LdaSmi), I8(-1),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(10),
B(Star), R(9),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(10),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(9),
[Interpreter] Add SetPendingMessage bytecode. Adds a bytecode to set and retrieve the pending message. This avoids a runtime call in finally blocks, and also ensures that TurboFan builds a graph using the SetMessage / LoadMessage nodes instead of inserting a runtime call. BUG=chromium:662334 Review-Url: https://codereview.chromium.org/2501503005 Cr-Commit-Position: refs/heads/master@{#41023}
2016-11-16 10:46:23 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(11),
B(Ldar), R(8),
B(JumpIfToBooleanTrue), U8(60),
B(LdaNamedProperty), R(5), U8(11), U8(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(Star), R(13),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(JumpIfUndefined), U8(52),
B(JumpIfNull), U8(50),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(JumpIfTrue), U8(18),
Throw TypeError if a proxy's [[OwnPropertyKeys]] returns dupes Adding implementation for step 9 which is missing for spec: https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys Update bytecode_expectations as well. Bug v8:6776 Change-Id: Id191f9604e2dc08e71cbcff8ebd5707c233af193 Reviewed-on: https://chromium-review.googlesource.com/c/1419779 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59180}
2019-01-28 18:53:22 +00:00
B(Wide), B(LdaSmi), I16(155),
[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),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(LdaConstant), U8(12),
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(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(CallRuntime), U16(Runtime::kNewTypeError), R(14), U8(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +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(14),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(CallProperty0), R(13), R(5), U8(15),
B(JumpIfJSReceiver), U8(21),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(15), U8(1),
B(Jump), U8(12),
B(Star), R(14),
B(LdaZero),
B(TestReferenceEqual), R(9),
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(14),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(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(11),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(SetPendingMessage),
B(Ldar), R(9),
B(SwitchOnSmiNoFeedback), U8(13), U8(2), I8(0),
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
B(Jump), U8(8),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Ldar), R(10),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(ReThrow),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Ldar), R(10),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
/* 44 S> */ B(Return),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 44 S> */ B(Return),
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
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 [22],
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
Smi [132],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +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,
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
Smi [16],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [9],
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
handlers: [
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
[79, 163, 171],
[217, 230, 232],
First version of the new generators implementation. Behind --ignition-generators. Does not yet support Turbofan. TBR=bmeurer@chromium.org BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1884183002 Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:04 +00:00
]
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
---
snippet: "
function* g() { yield 42 }
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: 9
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
parameter count: 1
[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
bytecode array length: 217
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +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),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(0),
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
/* 38 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
/* 38 E> */ B(SuspendGenerator), R(0), R(0), U8(1), U8(0),
B(ResumeGenerator), R(0), R(0), U8(1),
B(Star), R(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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +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(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 38 E> */ 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(Ldar), R(1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 54 S> */ B(Return),
[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
/* 43 S> */ B(LdaGlobal), U8(4), U8(0),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(Star), R(5),
/* 50 E> */ B(CallUndefinedReceiver0), 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(Star), R(6),
B(LdaNamedProperty), R(6), U8(5), U8(4),
B(Star), R(7),
B(CallProperty0), R(7), R(6), U8(6),
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), 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(Star), R(3),
B(LdaNamedProperty), R(3), U8(6), 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(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(LdaUndefined),
B(Star), R(4),
[ignition] desugar yield* in the BytecodeGenerator Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
2017-06-22 16:31:00 +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(2),
B(Ldar), R(2),
B(SwitchOnSmiNoFeedback), U8(7), U8(2), I8(1),
B(CallProperty1), R(5), R(3), R(4), U8(10),
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(69),
[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(3), U8(9), U8(12),
[ignition] desugar yield* in the BytecodeGenerator Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
2017-06-22 16:31:00 +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(8),
B(CallProperty1), R(8), R(3), R(4), U8(14),
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(52),
[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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 54 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(LdaNamedProperty), R(3), U8(10), U8(16),
[ignition] desugar yield* in the BytecodeGenerator Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
2017-06-22 16:31:00 +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(8),
B(CallProperty1), R(8), R(3), R(4), U8(18),
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(32),
[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(3), U8(9), U8(20),
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(JumpIfUndefined), U8(21),
B(JumpIfNull), 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(Star), R(8),
B(CallProperty0), R(8), R(3), U8(22),
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),
B(JumpIfJSReceiver), 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(Star), R(8),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(8), U8(1),
[ignition] desugar yield* in the BytecodeGenerator Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
2017-06-22 16:31:00 +00:00
B(CallRuntime), U16(Runtime::kThrowThrowMethodMissing), 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(Star), R(1),
[ignition] desugar yield* in the BytecodeGenerator Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
2017-06-22 16:31:00 +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(1), U8(1),
B(LdaNamedProperty), R(1), U8(11), U8(24),
B(JumpIfToBooleanTrue), U8(24),
B(Ldar), R(1),
/* 43 E> */ B(SuspendGenerator), R(0), R(0), U8(8), U8(1),
B(ResumeGenerator), R(0), R(0), U8(8),
B(Star), R(4),
[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(2),
B(JumpLoop), U8(114), I8(0),
B(LdaNamedProperty), R(1), U8(12), U8(26),
[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(3),
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
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(2),
[ignition] desugar yield* in the BytecodeGenerator Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
2017-06-22 16:31:00 +00:00
B(JumpIfFalse), 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(3),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 54 S> */ B(Return),
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
B(LdaUndefined),
/* 54 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 [22],
Smi [185],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["g"],
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 [31],
[generators] Improve yield* desugaring to save unnecessary try/catch and try/finally Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf Reviewed-on: https://chromium-review.googlesource.com/509256 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45466}
2017-05-22 14:52:07 +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"],
]
handlers: [
]
Reference in New Issue Copy Permalink