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

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

119 lines
3.4 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: "
Math.max(...[1, 2, 3]);
"
frame size: 3
parameter count: 1
[interpreter] Make FunctionEntry StackCheck bytecodes implicit FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
2020-02-10 16:09:27 +00:00
bytecode array length: 24
[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: [
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
/* 34 S> */ B(LdaGlobal), U8(0), U8(0),
[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(1),
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
/* 39 E> */ B(LdaNamedProperty), R(1), U8(1), 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(Star), R(0),
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
B(CreateArrayLiteral), U8(2), U8(4), U8(37),
[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(2),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
/* 39 E> */ B(CallWithSpread), R(0), R(1), U8(2), U8(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),
/* 58 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["Math"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["max"],
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
[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: "
Math.max(0, ...[1, 2, 3]);
"
frame size: 4
parameter count: 1
[interpreter] Make FunctionEntry StackCheck bytecodes implicit FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
2020-02-10 16:09:27 +00:00
bytecode array length: 27
[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: [
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
/* 34 S> */ B(LdaGlobal), U8(0), U8(0),
[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(1),
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
/* 39 E> */ B(LdaNamedProperty), R(1), U8(1), 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(Star), R(0),
B(LdaZero),
B(Star), R(2),
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
B(CreateArrayLiteral), U8(2), U8(4), U8(37),
[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(3),
[interpreter] Only create spread-related feedback slots when necessary. Only create spread-related feedback slots when the array literal actually contains a spread. Bug: v8:5940 Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49 Reviewed-on: https://chromium-review.googlesource.com/947955 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 10:22:47 +00:00
/* 39 E> */ B(CallWithSpread), R(0), R(1), U8(3), U8(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),
/* 61 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["Math"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["max"],
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
[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: "
Math.max(0, ...[1, 2, 3], 4);
"
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
frame size: 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
[interpreter] Make IterationBody StackChecks implicit within JumpLoop Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
2020-03-20 11:13:04 +00:00
bytecode array length: 100
[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: [
[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
/* 34 S> */ B(LdaGlobal), U8(0), U8(0),
[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),
[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(LdaNamedProperty), R(0), U8(1), U8(2),
[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(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
B(CreateArrayLiteral), U8(2), U8(4), U8(37),
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
B(Star), R(4),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(LdaConstant), U8(3),
B(Star), R(3),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
/* 49 S> */ B(CreateArrayLiteral), U8(4), U8(5), U8(37),
B(Star), R(7),
Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" This is a reland of 8b89a7c32d2a3dba3254b245b72fe87de5064b8d Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
2019-09-06 12:41:00 +00:00
B(GetIterator), R(7), U8(6), U8(8),
Revert "Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()" This reverts commit 91e3243d60153adb17947fb57bd85311924a47b4. Reason for revert: This deopts to the wrong point. Original change's description: > Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() > > Current GetIterator bytecode loads and calls @@iterator property on a > given object. This change extends the bytecode functionality to check > whether the value returned after calling @@iterator property is a valid > JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the > returned value is not a valid JSReceiver. This change absorbs the > functionality of additional two bytecodes - JumpIfJSReceiver and > CallRuntime, that are part of the iterator protocol in the GetIterator > bytecode. > > Bug: v8:9489 > Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Cr-Commit-Position: refs/heads/master@{#63704} TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9489 Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65541}
2019-12-20 14:06:40 +00:00
B(Mov), R(0), R(2),
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Reland "[parsing] inline ArrayLiteral creation for spread calls" This reverts commit f48e7349035430ea13dd0ce1ed1e775f6eecabeb. Reason for revert: innocent!! Original change's description: > Revert "[parsing] inline ArrayLiteral creation for spread calls" > > This reverts commit 93fc3841c3da0fc85662e66a57d881555238d634. > > Reason for revert: may break node.js integration > > Original change's description: > > [parsing] inline ArrayLiteral creation for spread calls > > > > Instead of using runtime calls to generate the Array Literal passed to > > %reflect_call / %reflect_construct, we create an ArrayLiteral from the > > list of arguments, and perform spreads using the interpreter mechanism for > > spreading in ArrayLiterals (thus, the spreading becomes inline). This > > array literal is still passed to %reflect_call / %reflect_construct as > > before. > > > > This cuts the runtime for bench-spread-call.js -> testSpread roughly in > > half, and will likely improve further once > > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed. > > > > BUG=v8:7446 > > R=​neis@chromium.org, adamk@chromium.org > > > > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad > > Reviewed-on: https://chromium-review.googlesource.com/939587 > > Commit-Queue: Georg Neis <neis@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#51678} > > TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org > > Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:7446 > Reviewed-on: https://chromium-review.googlesource.com/945769 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51682} TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7446 Reviewed-on: https://chromium-review.googlesource.com/945808 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51686}
2018-03-02 10:03:27 +00:00
B(Star), R(6),
Add GetIterator bytecode to load object[Symbol.iterator] in accumulator This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
2019-08-08 20:43:41 +00:00
B(LdaNamedProperty), R(6), U8(5), U8(10),
[ic] Introduce new IC for storing into array literals. ... and use it in the implementation of array literal spreads, replacing calls to %AppendElement. Array spreads in destructuring will be taken care of in a separate CL. Bug: v8:5940, v8:7446 Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0 Reviewed-on: https://chromium-review.googlesource.com/915364 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#51709}
2018-03-02 20:30:34 +00:00
B(Star), R(5),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(CallProperty0), R(5), R(6), U8(19),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(Star), R(7),
Reland "[parsing] inline ArrayLiteral creation for spread calls" This reverts commit f48e7349035430ea13dd0ce1ed1e775f6eecabeb. Reason for revert: innocent!! Original change's description: > Revert "[parsing] inline ArrayLiteral creation for spread calls" > > This reverts commit 93fc3841c3da0fc85662e66a57d881555238d634. > > Reason for revert: may break node.js integration > > Original change's description: > > [parsing] inline ArrayLiteral creation for spread calls > > > > Instead of using runtime calls to generate the Array Literal passed to > > %reflect_call / %reflect_construct, we create an ArrayLiteral from the > > list of arguments, and perform spreads using the interpreter mechanism for > > spreading in ArrayLiterals (thus, the spreading becomes inline). This > > array literal is still passed to %reflect_call / %reflect_construct as > > before. > > > > This cuts the runtime for bench-spread-call.js -> testSpread roughly in > > half, and will likely improve further once > > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed. > > > > BUG=v8:7446 > > R=​neis@chromium.org, adamk@chromium.org > > > > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad > > Reviewed-on: https://chromium-review.googlesource.com/939587 > > Commit-Queue: Georg Neis <neis@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#51678} > > TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org > > Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:7446 > Reviewed-on: https://chromium-review.googlesource.com/945769 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51682} TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7446 Reviewed-on: https://chromium-review.googlesource.com/945808 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51686}
2018-03-02 10:03:27 +00:00
B(JumpIfJSReceiver), U8(7),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(7), U8(1),
B(LdaNamedProperty), R(7), U8(6), U8(21),
[interpreter] Make IterationBody StackChecks implicit within JumpLoop Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
2020-03-20 11:13:04 +00:00
B(JumpIfToBooleanTrue), U8(19),
[ignition] Avoid possible unnecessary Mov around GetIterator Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
2019-08-23 14:23:52 +00:00
B(LdaNamedProperty), R(7), U8(7), U8(12),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(StaInArrayLiteral), R(4), R(3), U8(17),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Ldar), R(3),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(Inc), U8(16),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Star), R(3),
[interpreter] Make IterationBody StackChecks implicit within JumpLoop Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
2020-03-20 11:13:04 +00:00
B(JumpLoop), U8(33), I8(0),
Reland "[parsing] inline ArrayLiteral creation for spread calls" This reverts commit f48e7349035430ea13dd0ce1ed1e775f6eecabeb. Reason for revert: innocent!! Original change's description: > Revert "[parsing] inline ArrayLiteral creation for spread calls" > > This reverts commit 93fc3841c3da0fc85662e66a57d881555238d634. > > Reason for revert: may break node.js integration > > Original change's description: > > [parsing] inline ArrayLiteral creation for spread calls > > > > Instead of using runtime calls to generate the Array Literal passed to > > %reflect_call / %reflect_construct, we create an ArrayLiteral from the > > list of arguments, and perform spreads using the interpreter mechanism for > > spreading in ArrayLiterals (thus, the spreading becomes inline). This > > array literal is still passed to %reflect_call / %reflect_construct as > > before. > > > > This cuts the runtime for bench-spread-call.js -> testSpread roughly in > > half, and will likely improve further once > > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed. > > > > BUG=v8:7446 > > R=​neis@chromium.org, adamk@chromium.org > > > > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad > > Reviewed-on: https://chromium-review.googlesource.com/939587 > > Commit-Queue: Georg Neis <neis@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#51678} > > TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org > > Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:7446 > Reviewed-on: https://chromium-review.googlesource.com/945769 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51682} TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7446 Reviewed-on: https://chromium-review.googlesource.com/945808 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51686}
2018-03-02 10:03:27 +00:00
B(LdaSmi), I8(4),
[ignition] Move destructuring assignments to bytecode generation Instead of de-sugaring destructuring assignment in the parser (using the pattern rewriter), pass the Object/ArrayLiterals through to the bytecode generator, which can desugar them in-place. This allows us to decrease the amount of AST node creation, and improve the generated bytecode using domain-specific knowledge. As a side effect we partially fix an old execution ordering spec bug. Currently only implemented for assignments, not declarations, as the latter has some additional complexity. Bug: v8:4951 Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe Reviewed-on: https://chromium-review.googlesource.com/c/1375660 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-02 16:12:54 +00:00
B(StaInArrayLiteral), R(4), R(3), U8(17),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Mov), R(4), R(3),
[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(%reflect_apply), R(1), 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),
/* 64 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["Math"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["max"],
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
[ic] Introduce new IC for storing into array literals. ... and use it in the implementation of array literal spreads, replacing calls to %AppendElement. Array spreads in destructuring will be taken care of in a separate CL. Bug: v8:5940, v8:7446 Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0 Reviewed-on: https://chromium-review.googlesource.com/915364 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#51709}
2018-03-02 20:30:34 +00:00
Smi [1],
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
Reland "[parsing] inline ArrayLiteral creation for spread calls" This reverts commit f48e7349035430ea13dd0ce1ed1e775f6eecabeb. Reason for revert: innocent!! Original change's description: > Revert "[parsing] inline ArrayLiteral creation for spread calls" > > This reverts commit 93fc3841c3da0fc85662e66a57d881555238d634. > > Reason for revert: may break node.js integration > > Original change's description: > > [parsing] inline ArrayLiteral creation for spread calls > > > > Instead of using runtime calls to generate the Array Literal passed to > > %reflect_call / %reflect_construct, we create an ArrayLiteral from the > > list of arguments, and perform spreads using the interpreter mechanism for > > spreading in ArrayLiterals (thus, the spreading becomes inline). This > > array literal is still passed to %reflect_call / %reflect_construct as > > before. > > > > This cuts the runtime for bench-spread-call.js -> testSpread roughly in > > half, and will likely improve further once > > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed. > > > > BUG=v8:7446 > > R=​neis@chromium.org, adamk@chromium.org > > > > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad > > Reviewed-on: https://chromium-review.googlesource.com/939587 > > Commit-Queue: Georg Neis <neis@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#51678} > > TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org > > Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:7446 > Reviewed-on: https://chromium-review.googlesource.com/945769 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51682} TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7446 Reviewed-on: https://chromium-review.googlesource.com/945808 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51686}
2018-03-02 10:03:27 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
[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