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

330 lines
11 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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +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
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),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +00:00
Smi [21],
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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +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
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),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +00:00
Smi [21],
Smi [57],
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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
frame size: 15
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
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
bytecode array length: 246
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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +00:00
/* 11 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Mov), R(closure), R(4),
B(Mov), R(this), R(5),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(4), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(0),
/* 11 E> */ B(SuspendGenerator), R(0), R(0), U8(4), U8(0),
B(ResumeGenerator), R(0), R(0), U8(4),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Star), R(4),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[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),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(GetIterator), R(6), U8(1), U8(3),
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),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(5), U8(5), U8(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(Star), R(4),
B(LdaFalse),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(6),
B(Mov), R(context), R(9),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(LdaTrue),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(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
/* 25 S> */ B(CallProperty0), R(4), R(5), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(10),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(JumpIfJSReceiver), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), U8(1),
B(LdaNamedProperty), R(10), U8(6), U8(9),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(JumpIfToBooleanTrue), U8(64),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(LdaNamedProperty), R(10), U8(7), U8(11),
B(Star), R(10),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(LdaFalse),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(6),
B(Mov), R(10), 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 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 25 S> */ B(Mov), R(1), R(3),
[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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(12),
B(Mov), R(3), R(11),
B(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(11), U8(2),
/* 36 E> */ B(SuspendGenerator), R(0), R(0), U8(11), U8(1),
B(ResumeGenerator), R(0), R(0), U8(11),
B(Star), R(11),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(SwitchOnSmiNoFeedback), U8(8), U8(2), I8(0),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(11),
[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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(7),
B(Mov), R(11), 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(Jump), U8(20),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(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(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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(8),
B(Star), R(7),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(Jump), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(8),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(7),
[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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(9),
B(Ldar), R(6),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfToBooleanTrue), U8(58),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(5), U8(10), U8(13),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(11),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(50),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Mov), R(context), R(12),
[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),
[regexp] Improve String.prototype.matchAll error message Currently if the argument to matchAll has a null or undefined .flags property, the error message will read "String.prototype.matchAll called on null or undefined", which is very confusing. Drive-by fix: Remove the related and unused MethodInvokedOnNullOrUndefined error. Bug: v8:9895 Change-Id: I3644545282ac8d2156c7a51086e37a0ab7f97a78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874619 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64530}
2019-10-24 01:15:47 +00:00
B(Wide), B(LdaSmi), I16(159),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(13),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaConstant), U8(11),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(14),
B(CallRuntime), U16(Runtime::kNewTypeError), R(13), 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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(CallProperty0), R(11), R(5), U8(15),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(JumpIfJSReceiver), U8(21),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(1),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(Jump), U8(12),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(12),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(LdaZero),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(TestReferenceEqual), R(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(JumpIfTrue), U8(5),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(12),
[ignition] Move for-of desugaring to bytecode This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 14:15:52 +00:00
B(ReThrow),
B(Ldar), R(9),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(SetPendingMessage),
B(Ldar), R(7),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(SwitchOnSmiNoFeedback), U8(12), U8(2), I8(0),
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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(8),
[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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Ldar), R(8),
[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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +00:00
Smi [21],
Smi [118],
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
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"],
Revert recent ConsString-related changes We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b7011867cf2f2d50a509b03e39c54fe0e213e0. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 5758209026018a9ca573be234580077ad5974824. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0ee1921213320ecb4555e5d463406a4ab7. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
2019-04-18 09:29:49 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
[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: [
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
[66, 150, 158],
[182, 215, 217],
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();
"
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
frame size: 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
parameter count: 1
Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
2019-09-11 17:04:42 +00:00
bytecode array length: 198
[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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34: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
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),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@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),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(GetIterator), R(6), U8(4), U8(6),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Star), R(3),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(3), U8(5), 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),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(SwitchOnSmiNoFeedback), U8(6), U8(2), I8(1),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(CallProperty1), R(5), R(3), R(4), U8(10),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(63),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(3), U8(8), U8(12),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(11),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(6),
B(CallProperty1), R(6), R(3), R(4), U8(14),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(48),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@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),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(3), U8(9), U8(16),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(11),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(6),
B(CallProperty1), R(6), R(3), R(4), U8(18),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(Jump), U8(30),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(3), U8(8), U8(20),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpIfUndefinedOrNull), U8(19),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(6),
B(CallProperty0), R(6), 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] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(6),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), 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),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(1), U8(10), U8(24),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(JumpIfToBooleanTrue), U8(24),
B(Ldar), R(1),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
/* 43 E> */ B(SuspendGenerator), R(0), R(0), U8(6), U8(1),
B(ResumeGenerator), R(0), R(0), U8(6),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Star), R(4),
[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),
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
B(JumpLoop), U8(108), I8(0),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(1), U8(11), 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: [
[interpreter] Move function-entry stack check to start of bytecode array The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
2019-11-11 13:34:07 +00:00
Smi [21],
Smi [165],
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"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
Reland "[esnext] load `iterator.next` only once at beginning of iteration" https://github.com/tc39/ecma262/pull/988 gained concensus during the september 2017 TC39 meetings. This moves the load of the "next" method to the very beginning of the iteration protocol, rather than during each iteration step. This impacts: - yield* - for-of loops - spread arguments - array spreads In the v8 implementation, this also affects async iteration versions of these things (the sole exception being the Async-From-Sync iterator, which requires a few more changes to work with this, likely done in a followup patch). This change introduces a new AST node, ResolvedProperty, which can be used as a callee by Call nodes to produce the same bytecode as Property calls, without observably re-loading the property. This is used in several AST-desugarings involving the iteration protocol. BUG=v8:6861, v8:5699 R=rmcilroy@chromium.org TBR=neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b Reviewed-on: https://chromium-review.googlesource.com/857593 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50518}
2018-01-11 17:24:11 +00:00
Smi [11],
[interpreter] add JumpIfUndefinedOrNull Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
2019-08-08 15:56:48 +00:00
Smi [29],
[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