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

832 lines
29 KiB
Plaintext
Raw Normal View History

[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
module: yes
top level: yes
---
snippet: "
import \"bar\";
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 111
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
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(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 13 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 13 S> */ B(Return),
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
B(Ldar), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 13 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [59],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
]
handlers: [
]
---
snippet: "
import {foo} from \"bar\";
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 111
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
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(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 24 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 24 S> */ B(Return),
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
B(Ldar), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 24 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [59],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
]
handlers: [
]
---
snippet: "
import {foo as goo} from \"bar\";
goo(42);
{ let x; { goo(42) } };
"
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
frame size: 6
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 155
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
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(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 64 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 64 S> */ B(Return),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
/* 32 S> */ B(LdaModuleVariable), I8(-1), U8(0),
[Interpreter] Introduce bytecodes that check for hole and throw. Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
2017-06-06 09:00:22 +00:00
B(ThrowReferenceErrorIfHole), U8(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
B(Star), R(3),
[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(42),
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
B(Star), R(4),
/* 32 E> */ B(CallUndefinedReceiver1), R(3), R(4), U8(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(closure),
[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(CreateBlockContext), U8(5),
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
B(PushContext), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 47 S> */ B(LdaUndefined),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 47 E> */ B(StaCurrentContextSlot), U8(4),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
/* 52 S> */ B(LdaModuleVariable), I8(-1), U8(1),
[Interpreter] Introduce bytecodes that check for hole and throw. Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
2017-06-06 09:00:22 +00:00
B(ThrowReferenceErrorIfHole), U8(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
B(Star), R(4),
[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(42),
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
B(Star), R(5),
/* 52 E> */ B(CallUndefinedReceiver1), R(4), R(5), U8(5),
B(StaContextSlot), R(3), U8(5), U8(0),
B(PopContext), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 64 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [59],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["goo"],
FIXED_ARRAY_TYPE,
]
handlers: [
]
---
snippet: "
export var foo = 42;
foo++;
{ let x; { foo++ } };
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 153
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
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(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 49 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 49 S> */ B(Return),
[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
/* 17 S> */ B(LdaSmi), I8(42),
/* 17 E> */ B(StaModuleVariable), I8(1), U8(0),
/* 21 S> */ B(LdaModuleVariable), I8(1), U8(0),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-09 21:45:33 +00:00
B(Inc), U8(3),
[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
/* 24 E> */ B(StaModuleVariable), I8(1), U8(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(closure),
[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(CreateBlockContext), U8(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
B(PushContext), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 34 S> */ B(LdaUndefined),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 34 E> */ B(StaCurrentContextSlot), U8(4),
[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
/* 39 S> */ B(LdaModuleVariable), I8(1), U8(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
B(ToNumber), R(4), U8(4),
B(Ldar), R(4),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-09 21:45:33 +00:00
B(Inc), U8(4),
[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
/* 42 E> */ B(StaModuleVariable), I8(1), U8(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
B(Ldar), R(4),
B(StaContextSlot), R(3), U8(5), U8(0),
B(PopContext), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 49 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [59],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
]
handlers: [
]
---
snippet: "
export let foo = 42;
foo++;
{ let x; { foo++ } };
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 157
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
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(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[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(StaModuleVariable), I8(1), U8(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 49 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 49 S> */ B(Return),
[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
/* 17 S> */ B(LdaSmi), I8(42),
/* 17 E> */ B(StaModuleVariable), I8(1), U8(0),
/* 21 S> */ B(LdaModuleVariable), I8(1), U8(0),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-09 21:45:33 +00:00
B(Inc), U8(3),
[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
/* 24 E> */ B(StaModuleVariable), I8(1), U8(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(closure),
[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(CreateBlockContext), U8(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
B(PushContext), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 34 S> */ B(LdaUndefined),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 34 E> */ B(StaCurrentContextSlot), U8(4),
[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
/* 39 S> */ B(LdaModuleVariable), I8(1), U8(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
B(ToNumber), R(4), U8(4),
B(Ldar), R(4),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-09 21:45:33 +00:00
B(Inc), U8(4),
[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
/* 42 E> */ B(StaModuleVariable), I8(1), U8(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
B(Ldar), R(4),
B(StaContextSlot), R(3), U8(5), U8(0),
B(PopContext), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 49 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [63],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
]
handlers: [
]
---
snippet: "
export const foo = 42;
foo++;
{ let x; { foo++ } };
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 161
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
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(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[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(StaModuleVariable), I8(1), U8(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 51 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 51 S> */ B(Return),
[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
/* 19 S> */ B(LdaSmi), I8(42),
/* 19 E> */ B(StaModuleVariable), I8(1), U8(0),
/* 23 S> */ B(LdaModuleVariable), I8(1), U8(0),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-09 21:45:33 +00:00
B(Inc), U8(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 26 E> */ B(CallRuntime), U16(Runtime::kThrowConstAssignError), R(0), U8(0),
B(Ldar), R(closure),
[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(CreateBlockContext), U8(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
B(PushContext), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 36 S> */ B(LdaUndefined),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 36 E> */ B(StaCurrentContextSlot), U8(4),
[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
/* 41 S> */ B(LdaModuleVariable), I8(1), U8(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
B(ToNumber), R(4), U8(4),
B(Ldar), R(4),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-09 21:45:33 +00:00
B(Inc), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 44 E> */ B(CallRuntime), U16(Runtime::kThrowConstAssignError), R(0), U8(0),
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
B(Ldar), R(4),
B(StaContextSlot), R(3), U8(5), U8(0),
B(PopContext), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 51 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [63],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
]
handlers: [
]
---
snippet: "
export default (function () {});
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 122
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
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(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[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(StaModuleVariable), I8(1), U8(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 32 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 32 S> */ B(Return),
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
B(Ldar), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
[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(CreateClosure), U8(4), U8(3), U8(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(StaModuleVariable), I8(1), U8(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 32 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [63],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
---
snippet: "
export default (class {});
"
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
frame size: 8
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 155
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
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(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaTheHole),
[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(StaModuleVariable), I8(1), U8(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 26 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 26 S> */ B(Return),
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
B(Ldar), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
[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(CreateClosure), U8(4), U8(3), U8(0),
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
B(Star), R(3),
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(LdaTheHole),
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
B(Star), R(4),
[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(16),
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
B(Star), R(6),
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(LdaSmi), I8(24),
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
B(Star), R(7),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
B(Star), R(4),
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(3), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(3), U8(1),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(StaModuleVariable), I8(1), U8(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 26 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [63],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
---
snippet: "
export {foo as goo} from \"bar\"
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 111
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
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(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 30 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 30 S> */ B(Return),
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
B(Ldar), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 30 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [59],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
]
handlers: [
]
---
snippet: "
export * from \"bar\"
"
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
frame size: 5
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
parameter count: 2
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
bytecode array length: 111
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(StackCheck),
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(0),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 19 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 19 S> */ B(Return),
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
B(Ldar), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
B(LdaCurrentContextSlot), U8(5),
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
/* 19 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [59],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
FIXED_ARRAY_TYPE,
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
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],
[interpreter] Add some bytecode tests for modules. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:13 +00:00
]
handlers: [
]
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
---
snippet: "
import * as foo from \"bar\"
foo.f(foo, foo.x);
"
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
frame size: 7
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
parameter count: 2
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
bytecode array length: 149
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
bytecodes: [
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(Mov), R(new_target), R(0),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(0), U8(1),
B(PushContext), R(2),
B(RestoreGeneratorState), R(0),
B(Star), R(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Revert "[compiler] Drive optimizations with feedback vector" This reverts commit e39c9e020f53f161fff2bf8c617aa01f9459f31a. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
2017-06-13 13:24:05 +00:00
B(LdaSmi), I8(79),
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
B(Star), R(2),
B(CallRuntime), U16(Runtime::kAbort), R(2), U8(1),
[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(-2),
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(1),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(LdaConstant), U8(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
B(Star), R(4),
B(Mov), R(arg0), R(2),
B(Mov), R(closure), R(3),
B(CallRuntime), U16(Runtime::kPushModuleContext), R(2), U8(3),
B(PushContext), R(2),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
B(StaCurrentContextSlot), U8(4),
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(0),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
B(LdaZero),
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
B(Star), R(3),
B(CallRuntime), U16(Runtime::kGetModuleNamespace), R(3), U8(1),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(5),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
/* 0 E> */ B(StackCheck),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(3),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
B(LdaZero),
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
/* 0 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(Ldar), R(3),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
/* 45 S> */ B(Return),
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
B(RestoreGeneratorRegisters), R(0), R(0), U8(3),
[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(-2),
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(1),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(0), U8(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
B(Star), R(3),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +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),
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
B(Ldar), R(3),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
/* 0 E> */ B(Throw),
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
B(Ldar), R(3),
[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
/* 45 S> */ B(Return),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 27 S> */ B(LdaImmutableCurrentContextSlot), U8(5),
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(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
/* 30 E> */ B(LdaNamedProperty), R(4), U8(4), U8(5),
B(Star), R(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaImmutableCurrentContextSlot), U8(5),
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
B(Star), R(5),
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(LdaImmutableCurrentContextSlot), U8(5),
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
B(Star), R(6),
/* 41 E> */ B(LdaNamedProperty), R(6), U8(5), U8(7),
B(Star), R(6),
/* 31 E> */ B(CallProperty2), R(3), R(4), R(5), R(6), U8(3),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(StaCurrentContextSlot), U8(6),
B(LdaCurrentContextSlot), U8(6),
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
/* 45 S> */ B(Return),
]
constant pool: [
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [69],
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
FIXED_ARRAY_TYPE,
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
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],
[modules] Add namespace import snippet to test-bytecode-generator. R=rmcilroy@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460403002 Cr-Commit-Position: refs/heads/master@{#40694}
2016-11-02 09:30:24 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
]
handlers: [
]
Reference in New Issue Copy Permalink