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

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

1472 lines
54 KiB
Plaintext
Raw Normal View History

[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
test function name: f
---
snippet: "
function f(arr) {
for (let x of arr) { let y = x; }
}
f([1, 2, 3]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 16
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 262
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
/* 10 E> */ B(StackCheck),
B(LdaZero),
B(Star), R(6),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(context), R(13),
[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
/* 34 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(0),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(15),
[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(CallProperty0), R(15), R(arg0), U8(2),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(arg0), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(4),
[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
/* 29 S> */ B(LdaNamedProperty), R(4), U8(1), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(14),
[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(CallProperty0), R(14), R(4), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(5),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 29 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(5), U8(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(LdaNamedProperty), R(5), U8(2), U8(8),
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
B(JumpIfToBooleanTrue), U8(28),
[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(5), U8(3), U8(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(7),
B(LdaSmi), I8(2),
B(Star), R(6),
B(Mov), R(7), R(3),
/* 20 E> */ B(StackCheck),
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
B(Mov), R(3), R(1),
/* 49 S> */ B(Mov), R(1), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
B(Star), R(6),
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
B(JumpLoop), U8(53), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
/* 49 E> */ B(CreateCatchContext), R(14), U8(4), U8(5),
B(PushContext), R(14),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(6), U8(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(6),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kReThrow), R(15), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
B(Star), R(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(6), U8(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(4), U8(6), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(8),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(6), U8(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(8),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(14),
B(CallRuntime), U16(Runtime::kNewTypeError), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(13),
B(Mov), R(8), R(14),
B(Mov), R(4), R(15),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(14), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(14),
B(Ldar), R(closure),
B(CreateCatchContext), R(14), U8(4), U8(8),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(14),
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(8), R(13),
B(Mov), R(4), R(14),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(9),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(9), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(9), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(10),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 54 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[7, 124, 132],
[parser] Alternative fix for chromium:740591 - Previous fix is https://chromium-review.googlesource.com/c/583531 but it diverges Scopes created by PreParser from Scopes created by Parser. - This CL creates the inner block scope a bit earlier and (temporarily) pushes it into the scope chain for parsing the variable declarations in a for loop. The previous approach was to first parse the variable declarations and then reparent the AST nodes / Scopes created while parsing it afterwards. - This CL partially reverts https://chromium-review.googlesource.com/c/583531; the new fix only touches parser-base.h (diff between patch sets 2 and 3 is the fix). - The Ignition golden changes are basically undoing the changes done in that CL too. Bug: chromium:740591 Change-Id: Iceff1383ef066317e754942bb5ff0c70a91bc937 Reviewed-on: https://chromium-review.googlesource.com/603787 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47241}
2017-08-09 08:00:20 +00:00
[10, 88, 90],
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[192, 202, 204],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function f(arr) {
for (let x of arr) { eval('1'); }
}
f([1, 2, 3]);
"
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
frame size: 23
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 345
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
B(CreateFunctionContext), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(this),
B(StaCurrentContextSlot), U8(5),
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
B(CreateMappedArguments),
B(StaCurrentContextSlot), U8(7),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(StaCurrentContextSlot), U8(6),
/* 10 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(LdaZero),
B(Star), R(3),
B(Mov), R(context), R(12),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(13),
/* 34 S> */ B(LdaContextSlot), R(9), U8(4), U8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaNamedProperty), R(14), U8(1), U8(0),
B(Star), R(15),
B(CallProperty0), R(15), R(14), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
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
/* 29 S> */ B(LdaNamedProperty), R(1), U8(2), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(14),
[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(CallProperty0), R(14), R(1), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(2),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 29 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(2), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(2), U8(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(LdaNamedProperty), R(2), U8(3), U8(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanTrue), U8(78),
[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(2), U8(4), U8(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(4),
B(LdaSmi), I8(2),
B(Star), R(3),
B(Mov), R(4), R(0),
/* 20 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(4),
B(StaCurrentContextSlot), U8(4),
[interpreter] DYNAMIC_GLOBAL needs to walk the context chain starting from current_scope, not closure_scope The main reason why we currently don't see this fail is that block-scopes always appear to have an extension: the scope info object is stored there. Bug: Change-Id: I38f0c15387e235eeea9a57c95af0d9eb185dad2a Reviewed-on: https://chromium-review.googlesource.com/785951 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49585}
2017-11-22 16:40:24 +00:00
/* 41 S> */ B(LdaLookupGlobalSlot), U8(6), U8(12), U8(3),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(15),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaConstant), U8(7),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
B(Star), R(20),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(37),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(21),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(41),
B(Star), R(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(15), R(17),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(16), R(18),
B(Mov), R(closure), R(19),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(17), U8(6),
B(Star), R(15),
[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
/* 41 E> */ B(CallUndefinedReceiver1), R(15), R(16), U8(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
B(Star), R(3),
B(JumpLoop), U8(103), I8(0),
B(Jump), U8(36),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(CreateCatchContext), R(14), U8(8), U8(9),
B(PushContext), R(14),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(3), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(15),
B(CallRuntime), U16(Runtime::kReThrow), R(15), U8(1),
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(10),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Jump), U8(7),
B(Star), R(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(3), U8(17),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(1), U8(10), U8(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(5),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(3), U8(20),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(5),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaConstant), U8(11),
B(Star), R(14),
B(CallRuntime), U16(Runtime::kNewTypeError), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(13),
B(Mov), R(5), R(14),
B(Mov), R(1), R(15),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(14), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(14),
B(Ldar), R(closure),
B(CreateCatchContext), R(14), U8(8), U8(12),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(14),
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(5), R(13),
B(Mov), R(1), R(14),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(6),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(TestEqualStrictNoFeedback), R(10),
[interpreter] Avoid redundant {PopContext} instructions. This avoids emitting redundant {PopContext} bytecode instructions when non-local control-flow leaves the method body. It also folds multiple such {PopContext} instructions into one, in case several scoping levels are crossed at one. Only the expected context of the target of a local control-flow transfer matters. R=rmcilroy@chromium.org TEST=debugger/regress/regress-crbug-724858 BUG=chromium:724858 Change-Id: Id4a47ae9fea25e75ae1af13619720b16a3975edf Reviewed-on: https://chromium-review.googlesource.com/512545 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45507}
2017-05-24 08:08:21 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PopContext), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
/* 54 S> */ B(Return),
]
constant pool: [
FIXED_ARRAY_TYPE,
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["1"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[35, 205, 213],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
[38, 169, 171],
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[273, 283, 285],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function f(arr) {
for (let x of arr) { (function() { return x; })(); }
}
f([1, 2, 3]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 14
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 280
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
/* 10 E> */ B(StackCheck),
B(LdaZero),
B(Star), R(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(context), R(11),
[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
/* 34 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(0),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[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(CallProperty0), R(13), R(arg0), U8(2),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(arg0), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
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
/* 29 S> */ B(LdaNamedProperty), R(2), U8(1), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
[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(CallProperty0), R(12), R(2), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(3),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 29 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(3), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(3), U8(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(LdaNamedProperty), R(3), U8(2), U8(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanTrue), U8(46),
[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(3), U8(3), U8(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(5),
B(LdaSmi), I8(2),
B(Star), R(4),
B(Mov), R(5), R(1),
/* 20 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(5),
B(StaCurrentContextSlot), U8(4),
[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
/* 41 S> */ B(CreateClosure), U8(5), U8(12), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(13),
[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
/* 67 E> */ B(CallUndefinedReceiver0), R(13), U8(13),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
B(Star), R(4),
B(JumpLoop), U8(71), I8(0),
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(12),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(12), U8(6), U8(7),
B(PushContext), R(12),
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(4), U8(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(4),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(13),
B(CallRuntime), U16(Runtime::kReThrow), R(13), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
B(Star), R(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(4), U8(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(2), U8(8), U8(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(6),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(4), U8(19),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(6),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
B(CallRuntime), U16(Runtime::kNewTypeError), R(11), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(11),
B(Mov), R(6), R(12),
B(Mov), R(2), R(13),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(12), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(12),
B(Ldar), R(closure),
B(CreateCatchContext), R(12), U8(6), U8(10),
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(11),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(12),
B(PopContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(6), R(11),
B(Mov), R(2), R(12),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(11), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(7),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(7), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(7), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(8),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 73 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[7, 142, 150],
[parser] Alternative fix for chromium:740591 - Previous fix is https://chromium-review.googlesource.com/c/583531 but it diverges Scopes created by PreParser from Scopes created by Parser. - This CL creates the inner block scope a bit earlier and (temporarily) pushes it into the scope chain for parsing the variable declarations in a for loop. The previous approach was to first parse the variable declarations and then reparent the AST nodes / Scopes created while parsing it afterwards. - This CL partially reverts https://chromium-review.googlesource.com/c/583531; the new fix only touches parser-base.h (diff between patch sets 2 and 3 is the fix). - The Ignition golden changes are basically undoing the changes done in that CL too. Bug: chromium:740591 Change-Id: Iceff1383ef066317e754942bb5ff0c70a91bc937 Reviewed-on: https://chromium-review.googlesource.com/603787 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47241}
2017-08-09 08:00:20 +00:00
[10, 106, 108],
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[210, 220, 222],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function f(arr) {
for (let { x, y } of arr) { let z = x + y; }
}
f([{ x: 0, y: 3 }, { x: 1, y: 9 }, { x: -12, y: 17 }]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 19
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 300
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
/* 10 E> */ B(StackCheck),
B(LdaZero),
B(Star), R(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(context), R(16),
[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
/* 41 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(0),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(18),
[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(CallProperty0), R(18), R(arg0), U8(2),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(arg0), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(7),
[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
/* 36 S> */ B(LdaNamedProperty), R(7), U8(1), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[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(CallProperty0), R(17), R(7), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(8),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 36 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(8), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(8), U8(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(LdaNamedProperty), R(8), U8(2), U8(8),
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
B(JumpIfToBooleanTrue), U8(66),
[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(8), U8(3), U8(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(10),
B(LdaSmi), I8(2),
B(Star), R(9),
B(Mov), R(10), R(5),
/* 20 E> */ B(StackCheck),
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
B(Mov), R(5), R(6),
[ignition] Fix register flushing performance issue In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
2017-06-09 09:26:27 +00:00
B(Ldar), R(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfUndefined), U8(6),
B(Ldar), R(6),
B(JumpIfNotNull), U8(16),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(LdaSmi), I8(74),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(18),
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
/* 31 E> */ B(Throw),
[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
/* 31 S> */ B(LdaNamedProperty), R(6), U8(4), U8(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +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
/* 34 S> */ B(LdaNamedProperty), R(6), U8(5), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(2),
[inspector] moved var initialization break location before init expression (reland) This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294 Reviewed-on: https://chromium-review.googlesource.com/518116 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45598}
2017-05-30 12:25:55 +00:00
/* 56 S> */ B(Ldar), 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
/* 58 E> */ B(Add), R(1), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(0),
B(LdaZero),
B(Star), R(9),
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
B(JumpLoop), U8(91), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(17),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
/* 56 E> */ B(CreateCatchContext), R(17), U8(6), U8(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PushContext), R(17),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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(TestEqualStrict), R(9), U8(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(9),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(18),
B(CallRuntime), U16(Runtime::kReThrow), R(18), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(9), U8(18),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(LdaNamedProperty), R(7), U8(8), U8(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(11),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(9), U8(21),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(11),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(16),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
B(LdaConstant), U8(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kNewTypeError), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(16),
B(Mov), R(11), R(17),
B(Mov), R(7), R(18),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(17), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(17),
B(Ldar), R(closure),
B(CreateCatchContext), R(17), U8(6), U8(10),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(17),
B(PopContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(11), R(16),
B(Mov), R(7), R(17),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(12),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(12), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(12), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(13),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 65 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["y"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[7, 162, 170],
[parser] Alternative fix for chromium:740591 - Previous fix is https://chromium-review.googlesource.com/c/583531 but it diverges Scopes created by PreParser from Scopes created by Parser. - This CL creates the inner block scope a bit earlier and (temporarily) pushes it into the scope chain for parsing the variable declarations in a for loop. The previous approach was to first parse the variable declarations and then reparent the AST nodes / Scopes created while parsing it afterwards. - This CL partially reverts https://chromium-review.googlesource.com/c/583531; the new fix only touches parser-base.h (diff between patch sets 2 and 3 is the fix). - The Ignition golden changes are basically undoing the changes done in that CL too. Bug: chromium:740591 Change-Id: Iceff1383ef066317e754942bb5ff0c70a91bc937 Reviewed-on: https://chromium-review.googlesource.com/603787 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47241}
2017-08-09 08:00:20 +00:00
[10, 126, 128],
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
[230, 240, 242],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function* f(arr) {
for (let x of arr) { let y = x; }
}
f([1, 2, 3]);
"
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
frame size: 19
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 341
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(3),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfUndefined), U8(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(3), U8(1),
B(PushContext), R(12),
B(RestoreGeneratorState), R(3),
B(Star), R(11),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Refactor bailout reasons This patch breaks out bailout reasons into two enum classes. This helps save 3 bits on the SharedFunctionInfo as we don't have to track the abort reasons. Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97 Reviewed-on: https://chromium-review.googlesource.com/848244 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50364}
2018-01-03 23:27:03 +00:00
B(Abort), U8(15),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(-2),
B(Star), R(11),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(closure), R(13),
B(Mov), R(this), R(14),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(13), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(3),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 11 E> */ B(StackCheck),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 11 E> */ B(SuspendGenerator), R(3), R(0), U8(13), U8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 55 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(3), R(0), U8(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(11),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(3), U8(1),
B(Star), R(13),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(3), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(2), I8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(13),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(13),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 55 S> */ B(Return),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(15),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 35 S> */ B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(17),
B(LdaNamedProperty), R(17), U8(3), U8(0),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(CallProperty0), R(18), R(17), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(5),
[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
/* 30 S> */ B(LdaNamedProperty), R(5), U8(4), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(17),
[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(CallProperty0), R(17), R(5), U8(6),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
/* 30 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(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(LdaNamedProperty), R(6), U8(5), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfToBooleanTrue), U8(28),
[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(6), U8(6), U8(10),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaSmi), I8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(Mov), R(8), R(4),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 21 E> */ B(StackCheck),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(4), R(1),
/* 50 S> */ B(Mov), R(1), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(JumpLoop), U8(53), I8(0),
B(Jump), U8(36),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(closure),
/* 50 E> */ B(CreateCatchContext), R(17), U8(7), U8(8),
B(PushContext), R(17),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(7), U8(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(18),
B(CallRuntime), U16(Runtime::kReThrow), R(18), U8(1),
B(PopContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(13),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(Jump), U8(7),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaZero),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(7), U8(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(5), U8(9), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(7), U8(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Ldar), R(9),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(16),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(LdaConstant), U8(10),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kNewTypeError), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(16),
B(Mov), R(9), R(17),
B(Mov), R(5), R(18),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(17), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(17),
B(Ldar), R(closure),
B(CreateCatchContext), R(17), U8(7), U8(11),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(17),
B(PopContext), R(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(9), R(16),
B(Mov), R(5), R(17),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(16), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(10),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(10), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(TestEqualStrictNoFeedback), R(13),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 55 S> */ B(Return),
]
constant pool: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [37],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
[85, 203, 211],
[88, 167, 169],
[271, 281, 283],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function* f(arr) {
for (let x of arr) yield x;
}
f([1, 2, 3]);
"
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
frame size: 18
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 408
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(2),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfUndefined), U8(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(2), U8(1),
B(PushContext), R(11),
B(RestoreGeneratorState), R(2),
B(Star), R(10),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(2), I8(0),
Refactor bailout reasons This patch breaks out bailout reasons into two enum classes. This helps save 3 bits on the SharedFunctionInfo as we don't have to track the abort reasons. Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97 Reviewed-on: https://chromium-review.googlesource.com/848244 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50364}
2018-01-03 23:27:03 +00:00
B(Abort), U8(15),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(-2),
B(Star), R(10),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(closure), R(12),
B(Mov), R(this), R(13),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(12), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 11 E> */ B(StackCheck),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 11 E> */ B(SuspendGenerator), R(2), R(0), U8(12), U8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 49 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(2), R(0), U8(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(10),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(2), U8(1),
B(Star), R(12),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(12),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(12),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
/* 49 S> */ B(Return),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(14),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(15),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 35 S> */ B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(16),
B(LdaNamedProperty), R(16), U8(4), U8(0),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(CallProperty0), R(17), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(10),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(5), U8(1), I8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 35 E> */ B(TestEqualStrictNoFeedback), R(10),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfTrue), U8(4),
Refactor bailout reasons This patch breaks out bailout reasons into two enum classes. This helps save 3 bits on the SharedFunctionInfo as we don't have to track the abort reasons. Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97 Reviewed-on: https://chromium-review.googlesource.com/848244 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50364}
2018-01-03 23:27:03 +00:00
B(Abort), U8(15),
[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
/* 30 S> */ B(LdaNamedProperty), R(4), U8(6), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(16),
[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(CallProperty0), R(16), R(4), U8(6),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(5),
/* 30 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(5), U8(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(LdaNamedProperty), R(5), U8(7), U8(8),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator Remove need for shuffling of accumulator and operand registers when suspending a generator BUG=v8:6351 TBR=bmeurer@chromium.org Change-Id: I372509adc03b9781716412b809639554fe16e372 Reviewed-on: https://chromium-review.googlesource.com/578377 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46883}
2017-07-25 18:37:36 +00:00
B(JumpIfToBooleanTrue), U8(74),
[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(5), U8(8), U8(10),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaSmi), I8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
B(Mov), R(7), R(3),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 21 E> */ B(StackCheck),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(3), R(0),
[interpreter] refactor BuildGeneratorSuspend/Resume into BuildSuspendPoint Simplify the model for generating Awaits, because the resume point is always immediately following the suspend point, and registers used are always the same for both operations. Includes a minor refactoring of BytecodeGenerator::VisitYield() to perform iterator result creation before the SuspendGenerator bytecode, rather than between SuspendGenerator and Return. This adds a small number of bytecodes for each yield. BUG=v8:2355, v8:5855 Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089 Reviewed-on: https://chromium-review.googlesource.com/576286 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46820}
2017-07-20 12:35:28 +00:00
/* 40 S> */ B(LdaFalse),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(17),
B(Mov), R(0), R(16),
B(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(16), U8(2),
B(SuspendGenerator), R(2), R(0), U8(16), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 49 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(2), R(0), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(10),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(2), U8(1),
B(Star), R(16),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(9), U8(2), I8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(16),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 40 E> */ B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(12),
B(Mov), R(16), R(13),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(58),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpLoop), U8(113), I8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(36),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(16),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(16), U8(11), U8(12),
B(PushContext), R(16),
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(6), U8(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kReThrow), R(17), U8(1),
B(PopContext), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(13),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(12),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(Jump), U8(8),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(1),
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(6), U8(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(4), U8(13), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(6), U8(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Ldar), R(8),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(15),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(LdaConstant), U8(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(16),
B(CallRuntime), U16(Runtime::kNewTypeError), R(15), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(15),
B(Mov), R(8), R(16),
B(Mov), R(4), R(17),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(16), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(16),
B(Ldar), R(closure),
B(CreateCatchContext), R(16), U8(11), U8(15),
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(15),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(16),
B(PopContext), R(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(8), R(15),
B(Mov), R(4), R(16),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(15), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(9),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(9), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(9), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(12),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(SwitchOnSmiNoFeedback), U8(16), U8(2), I8(0),
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
B(Jump), U8(8),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 49 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 49 S> */ B(Return),
]
constant pool: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [37],
Smi [97],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
SYMBOL_TYPE,
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [75],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
Smi [15],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [9],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
[85, 263, 271],
[88, 227, 229],
[332, 342, 344],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
async function f(arr) {
for (let x of arr) { let y = x; }
}
f([1, 2, 3]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 23
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 386
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
B(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 16 E> */ B(StackCheck),
[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(%async_function_promise_create), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(15),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(context), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(19),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(context), R(20),
/* 40 S> */ B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(21),
[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(21), U8(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(22),
[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(CallProperty0), R(22), R(21), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(5),
[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
/* 35 S> */ B(LdaNamedProperty), R(5), U8(1), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(21),
[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(CallProperty0), R(21), R(5), U8(6),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
/* 35 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(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(LdaNamedProperty), R(6), U8(2), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfToBooleanTrue), U8(28),
[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(6), U8(3), U8(10),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaSmi), I8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(Mov), R(8), R(4),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 26 E> */ B(StackCheck),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(4), R(1),
/* 55 S> */ B(Mov), R(1), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(JumpLoop), U8(53), I8(0),
B(Jump), U8(40),
B(Star), R(21),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
/* 55 E> */ B(CreateCatchContext), R(21), U8(4), U8(5),
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(20),
B(PushContext), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(7), U8(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(22),
B(CallRuntime), U16(Runtime::kReThrow), R(22), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(18),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(18),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(7), U8(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(5), U8(6), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(7), U8(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Ldar), R(9),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(20),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(LdaConstant), U8(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(21),
B(CallRuntime), U16(Runtime::kNewTypeError), R(20), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(20),
B(Mov), R(9), R(21),
B(Mov), R(5), R(22),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(21), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(21),
B(Ldar), R(closure),
B(CreateCatchContext), R(21), U8(4), U8(8),
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(20),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(21),
B(PopContext), R(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(9), R(20),
B(Mov), R(5), R(21),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(20), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(10),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(10), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(17),
[interpreter] Avoid redundant {PopContext} instructions. This avoids emitting redundant {PopContext} bytecode instructions when non-local control-flow leaves the method body. It also folds multiple such {PopContext} instructions into one, in case several scoping levels are crossed at one. Only the expected context of the target of a local control-flow transfer matters. R=rmcilroy@chromium.org TEST=debugger/regress/regress-crbug-724858 BUG=chromium:724858 Change-Id: Id4a47ae9fea25e75ae1af13619720b16a3975edf Reviewed-on: https://chromium-review.googlesource.com/512545 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45507}
2017-05-24 08:08:21 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
[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(18),
B(Mov), R(11), R(17),
B(CallJSRuntime), U8(%promise_resolve), R(17), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
B(Mov), R(11), R(14),
[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(Jump), U8(58),
B(Jump), U8(42),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(17),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(CreateCatchContext), R(17), U8(4), U8(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(16),
B(PushContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaFalse),
[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(20),
B(Mov), R(11), R(18),
B(CallJSRuntime), U8(%promise_internal_reject), R(18), U8(3),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(17),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
B(Mov), R(11), R(14),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(1),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(15),
[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(%async_function_promise_release), R(11), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(SwitchOnSmiNoFeedback), U8(10), U8(2), I8(0),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(Jump), U8(8),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 60 S> */ B(Return),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 60 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Smi [9],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
[18, 345, 353],
[21, 303, 305],
[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
[27, 149, 157],
[30, 109, 111],
[217, 227, 229],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
async function f(arr) {
for (let x of arr) await x;
}
f([1, 2, 3]);
"
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
frame size: 24
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
bytecode array length: 480
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(2),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfUndefined), U8(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(2), U8(1),
B(PushContext), R(12),
B(RestoreGeneratorState), R(2),
B(Star), R(11),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
Refactor bailout reasons This patch breaks out bailout reasons into two enum classes. This helps save 3 bits on the SharedFunctionInfo as we don't have to track the abort reasons. Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97 Reviewed-on: https://chromium-review.googlesource.com/848244 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50364}
2018-01-03 23:27:03 +00:00
B(Abort), U8(15),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(-2),
B(Star), R(11),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(closure), R(13),
B(Mov), R(this), R(14),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(13), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(2),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 16 E> */ B(StackCheck),
[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(%async_function_promise_create), R(0), U8(0),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(10),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(15),
[ignition] Fix register flushing performance issue In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
2017-06-09 09:26:27 +00:00
B(Mov), R(context), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(6),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(19),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(20),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 40 S> */ B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(21),
B(LdaNamedProperty), R(21), U8(1), U8(0),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(CallProperty0), R(22), R(21), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(11),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(1), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 40 E> */ B(TestEqualStrictNoFeedback), R(11),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfTrue), U8(4),
Refactor bailout reasons This patch breaks out bailout reasons into two enum classes. This helps save 3 bits on the SharedFunctionInfo as we don't have to track the abort reasons. Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97 Reviewed-on: https://chromium-review.googlesource.com/848244 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50364}
2018-01-03 23:27:03 +00:00
B(Abort), U8(15),
[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
/* 35 S> */ B(LdaNamedProperty), R(4), U8(3), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(21),
[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(CallProperty0), R(21), R(4), U8(6),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(5),
/* 35 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(5), U8(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(LdaNamedProperty), R(5), U8(4), U8(8),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator Remove need for shuffling of accumulator and operand registers when suspending a generator BUG=v8:6351 TBR=bmeurer@chromium.org Change-Id: I372509adc03b9781716412b809639554fe16e372 Reviewed-on: https://chromium-review.googlesource.com/578377 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46883}
2017-07-25 18:37:36 +00:00
B(JumpIfToBooleanTrue), U8(72),
[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(5), U8(5), U8(10),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(Star), R(7),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(LdaSmi), I8(2),
B(Star), R(6),
B(Mov), R(7), R(3),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 26 E> */ B(StackCheck),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Mov), R(3), R(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 45 S> */ B(Mov), R(2), R(21),
B(Mov), R(0), R(22),
B(Mov), R(10), R(23),
B(CallJSRuntime), U8(%async_function_await_uncaught), R(21), U8(3),
B(SuspendGenerator), R(2), R(0), U8(21), U8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 54 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(2), R(0), U8(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(11),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(2), U8(1),
B(Star), R(21),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
[interpreter] refactor BuildGeneratorSuspend/Resume into BuildSuspendPoint Simplify the model for generating Awaits, because the resume point is always immediately following the suspend point, and registers used are always the same for both operations. Includes a minor refactoring of BytecodeGenerator::VisitYield() to perform iterator result creation before the SuspendGenerator bytecode, rather than between SuspendGenerator and Return. This adds a small number of bytecodes for each yield. BUG=v8:2355, v8:5855 Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089 Reviewed-on: https://chromium-review.googlesource.com/576286 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46820}
2017-07-20 12:35:28 +00:00
B(Star), R(22),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(TestEqualStrictNoFeedback), R(22),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(JumpIfTrue), U8(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(21),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(ReThrow),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(6),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpLoop), U8(111), I8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(40),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(21),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(21), U8(6), U8(7),
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(20),
B(PushContext), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[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(TestEqualStrict), R(6), U8(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(22),
B(CallRuntime), U16(Runtime::kReThrow), R(22), U8(1),
B(PopContext), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(17),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Jump), U8(7),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaZero),
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrict), R(6), U8(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfTrue), U8(104),
[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(4), U8(8), U8(14),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(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
B(TestEqualStrict), R(6), U8(16),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(JumpIfFalse), U8(61),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Ldar), R(8),
[bigint] Fix typeof. The bytecode generator has special handling for comparing the result of the typeof operator against a string literal. This needs to be adapted for bigints. R=jkummerow@chromium.org, mythrie@chromium.org Bug: v8:6791 Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c Reviewed-on: https://chromium-review.googlesource.com/753465 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 09:26:56 +00:00
B(TestTypeOf), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[class] Ban arguments in class field initializers Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 22:36:27 +00:00
B(Wide), B(LdaSmi), I16(144),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(20),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(LdaConstant), U8(9),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(21),
B(CallRuntime), U16(Runtime::kNewTypeError), R(20), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(context), R(20),
B(Mov), R(8), R(21),
B(Mov), R(4), R(22),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(21), U8(2),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(Jump), U8(20),
B(Star), R(21),
B(Ldar), R(closure),
B(CreateCatchContext), R(21), U8(6), U8(10),
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(20),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(PushContext), R(21),
B(PopContext), R(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Mov), R(8), R(20),
B(Mov), R(4), R(21),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(20), U8(2),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(Star), R(9),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(9), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(9), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(TestEqualStrictNoFeedback), R(17),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
[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(18),
B(Mov), R(10), R(17),
B(CallJSRuntime), U8(%promise_resolve), R(17), U8(2),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(13),
B(Mov), R(10), R(14),
[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(Jump), U8(58),
B(Jump), U8(42),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(closure),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(CreateCatchContext), R(17), U8(6), U8(11),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(16),
B(PushContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(19),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(LdaFalse),
[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(20),
B(Mov), R(10), R(18),
B(CallJSRuntime), U8(%promise_internal_reject), R(18), U8(3),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PopContext), R(17),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(13),
B(Mov), R(10), R(14),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(13),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(Jump), U8(8),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(1),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(15),
[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(%async_function_promise_release), R(10), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(13),
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
B(SwitchOnSmiNoFeedback), U8(12), U8(2), I8(0),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(Jump), U8(8),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 54 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 54 S> */ B(Return),
]
constant pool: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [75],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
SYMBOL_TYPE,
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [78],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
FIXED_ARRAY_TYPE,
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Smi [9],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
Revert "[language] Implement optional catch binding proposal" This reverts commit d0651bd108e0ee70ae822eda9bad7049cb2f3df4. Reason for revert: Breaks gc stress with embedded snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 Original change's description: > [language] Implement optional catch binding proposal > > This allows the syntax `try {} catch {}` (with no binding after the > `catch`). > > See https://github.com/michaelficarra/optional-catch-binding-proposal/ > > Currently behind --harmony-optional-catch-binding. > > As part of the implementation, this allows TryCatchStatements to not > have an associated catch scope; various paths which assumed they > would have been updated to handle this case. > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f > Reviewed-on: https://chromium-review.googlesource.com/571453 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Kevin Gibbons <bakkot@gmail.com> > Cr-Commit-Position: refs/heads/master@{#48300} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/702334 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:30:58 +00:00
[54, 439, 447],
[57, 397, 399],
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
[63, 243, 251],
[66, 203, 205],
[311, 321, 323],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
Reference in New Issue Copy Permalink