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

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

137 lines
4.0 KiB
Plaintext
Raw Normal View History

[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: yes
---
snippet: "
class A { constructor(...args) { this.args = args; } }
new A(...[1, 2, 3]);
"
[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
frame size: 7
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
parameter count: 1
[turbofan] Add IC support for Call/ConstructWithSpread. Properly hook up the (existing) IC slots for the CallWithSpread and ConstructWithSpread bytecodes, and change the interpreter to collect feedback (call counts and regular target function feedback) for those. There's no integration with the Array constructor yet, since that requires some yak shaving to thread through the AllocationSite to the Array constructor stub. Once we have a solution for that, we can also remove the current code duplication in the Call/Construct IC logic. Also properly hook up the newly available feedback in TurboFan. This will fix not only the missing target feedback, but more importantly the tear-up decisions for optimization are correct now in the presence of spread calls, and even more importantly the inlining heurstic has proper call frequencies for those. Some follow-up changes will be necessary to make sure we use the feedback even for corner cases that aren't handled properly yet. Also we should consider collecting feedback about the map of the spread at some point to be able to always inline the spread calls. Bug: v8:6399, v8:6527, v8:6630 Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00 Reviewed-on: https://chromium-review.googlesource.com/582647 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46832}
2017-07-23 07:16:24 +00:00
bytecode array length: 57
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
bytecodes: [
/* 30 E> */ B(StackCheck),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(CreateClosure), U8(0), U8(0), U8(2),
[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(Star), R(2),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(LdaTheHole),
[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(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(34),
[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(Star), R(5),
[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(88),
[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(Star), R(6),
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(2), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(1),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(Star), R(0),
B(Star), R(1),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 89 S> */ B(CreateArrayLiteral), U8(1), U8(3), U8(37),
[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(Star), R(3),
B(Ldar), R(1),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 89 E> */ B(ConstructWithSpread), R(1), R(3), U8(1), U8(1),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(LdaUndefined),
/* 110 S> */ B(Return),
]
constant pool: [
SHARED_FUNCTION_INFO_TYPE,
Do not use new struct type where unnecessary. We can use TUPLE2 or TUPLE3 for structs that do not need special handling by deoptimizer and compiler. This frees up a few instance types, so that adding the next few new structs will not cause ABI compatibility to break. R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2811183005 Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
TUPLE2_TYPE,
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
]
handlers: [
]
---
snippet: "
class A { constructor(...args) { this.args = args; } }
new A(0, ...[1, 2, 3]);
"
[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
frame size: 7
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
parameter count: 1
[turbofan] Add IC support for Call/ConstructWithSpread. Properly hook up the (existing) IC slots for the CallWithSpread and ConstructWithSpread bytecodes, and change the interpreter to collect feedback (call counts and regular target function feedback) for those. There's no integration with the Array constructor yet, since that requires some yak shaving to thread through the AllocationSite to the Array constructor stub. Once we have a solution for that, we can also remove the current code duplication in the Call/Construct IC logic. Also properly hook up the newly available feedback in TurboFan. This will fix not only the missing target feedback, but more importantly the tear-up decisions for optimization are correct now in the presence of spread calls, and even more importantly the inlining heurstic has proper call frequencies for those. Some follow-up changes will be necessary to make sure we use the feedback even for corner cases that aren't handled properly yet. Also we should consider collecting feedback about the map of the spread at some point to be able to always inline the spread calls. Bug: v8:6399, v8:6527, v8:6630 Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00 Reviewed-on: https://chromium-review.googlesource.com/582647 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46832}
2017-07-23 07:16:24 +00:00
bytecode array length: 60
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
bytecodes: [
/* 30 E> */ B(StackCheck),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(CreateClosure), U8(0), U8(0), U8(2),
[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(Star), R(2),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(LdaTheHole),
[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(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(34),
[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(Star), R(5),
[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(88),
[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(Star), R(6),
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(2), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(1),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(Star), R(0),
B(Star), R(1),
/* 89 S> */ B(LdaZero),
[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(Star), R(3),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(CreateArrayLiteral), U8(1), U8(3), U8(37),
[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(Star), R(4),
B(Ldar), R(1),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 89 E> */ B(ConstructWithSpread), R(1), R(3), U8(2), U8(1),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(LdaUndefined),
/* 113 S> */ B(Return),
]
constant pool: [
SHARED_FUNCTION_INFO_TYPE,
Do not use new struct type where unnecessary. We can use TUPLE2 or TUPLE3 for structs that do not need special handling by deoptimizer and compiler. This frees up a few instance types, so that adding the next few new structs will not cause ABI compatibility to break. R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2811183005 Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
TUPLE2_TYPE,
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
]
handlers: [
]
---
snippet: "
class A { constructor(...args) { this.args = args; } }
new A(0, ...[1, 2, 3], 4);
"
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
frame size: 7
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
parameter count: 1
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
bytecode array length: 81
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
bytecodes: [
/* 30 E> */ B(StackCheck),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(CreateClosure), U8(0), U8(0), U8(2),
[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(Star), R(2),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(LdaTheHole),
[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(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(34),
[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(Star), R(5),
[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(88),
[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(Star), R(6),
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(2), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(1),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(Star), R(0),
B(Star), R(1),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
/* 89 S> */ B(CreateArrayLiteral), U8(1), U8(1), U8(37),
B(Star), R(3),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(CreateArrayLiteral), U8(2), U8(2), U8(37),
[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(Star), R(4),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(CallJSRuntime), U8(%spread_iterable), R(4), U8(1),
B(Star), R(4),
B(CreateArrayLiteral), U8(3), U8(3), U8(37),
B(Star), R(5),
B(CallJSRuntime), U8(%spread_arguments), R(3), U8(3),
B(Star), R(3),
B(Mov), R(1), R(2),
B(CallJSRuntime), U8(%reflect_construct), R(2), U8(2),
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
B(LdaUndefined),
/* 116 S> */ B(Return),
]
constant pool: [
SHARED_FUNCTION_INFO_TYPE,
Do not use new struct type where unnecessary. We can use TUPLE2 or TUPLE3 for structs that do not need special handling by deoptimizer and compiler. This frees up a few instance types, so that adding the next few new structs will not cause ABI compatibility to break. R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2811183005 Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
TUPLE2_TYPE,
TUPLE2_TYPE,
TUPLE2_TYPE,
[Ignition/turbo] Add a CallWithSpread bytecode. Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2629363002 Cr-Original-Commit-Position: refs/heads/master@{#42455} Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0 Review-Url: https://codereview.chromium.org/2629363002 Cr-Commit-Position: refs/heads/master@{#42590}
2017-01-23 09:03:35 +00:00
]
handlers: [
]
Reference in New Issue Copy Permalink