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

143 lines
4.2 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
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 56
[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),
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(CreateClosure), U8(0), U8(3), 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),
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
/* 89 S> */ B(CreateArrayLiteral), U8(1), U8(6), U8(17),
[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),
/* 89 E> */ B(ConstructWithSpread), R(1), R(3), 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
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 59
[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),
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(CreateClosure), U8(0), U8(3), 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),
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(CreateArrayLiteral), U8(1), U8(6), U8(17),
[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),
/* 89 E> */ B(ConstructWithSpread), R(1), R(3), 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),
/* 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);
"
[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: 8
[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
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 90
[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),
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(CreateClosure), U8(0), U8(3), 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(LdaUndefined),
[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(LdaUndefined),
[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),
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
/* 93 E> */ B(CreateArrayLiteral), U8(1), U8(4), U8(17),
[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/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),
[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),
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(CreateArrayLiteral), U8(2), U8(5), U8(17),
[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(7),
[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(CallJSRuntime), U8(%spread_iterable), R(6), U8(2),
B(Star), R(6),
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(CreateArrayLiteral), U8(3), U8(6), U8(17),
[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(7),
B(CallJSRuntime), U8(%spread_arguments), R(4), U8(4),
B(Star), R(4),
B(Mov), R(0), R(3),
B(CallJSRuntime), U8(%reflect_construct), R(2), U8(3),
[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