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

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

496 lines
15 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() {
for (let x = 0; x < 10; ++x) { let y = x; }
}
f();
"
frame size: 2
parameter count: 1
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 26
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
/* 30 S> */ B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), 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
/* 35 S> */ B(LdaSmi), I8(10),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 35 E> */ B(TestLessThan), R(0), U8(0),
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(JumpIfFalse), 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
/* 17 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 56 S> */ B(Mov), R(0), R(1),
/* 43 S> */ B(Ldar), R(1),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(0),
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(17), 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(LdaUndefined),
/* 61 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f() {
for (let x = 0; x < 10; ++x) { eval('1'); }
}
f();
"
[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: 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
parameter count: 1
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
bytecode array length: 165
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
B(CreateFunctionContext), U8(0), 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(PushContext), 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
B(Ldar), R(this),
B(StaCurrentContextSlot), U8(4),
B(CreateMappedArguments),
B(StaCurrentContextSlot), U8(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(Ldar), 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
B(StaCurrentContextSlot), U8(5),
/* 10 E> */ B(StackCheck),
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
B(CreateBlockContext), 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(5),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
/* 30 S> */ B(LdaZero),
/* 30 E> */ B(StaCurrentContextSlot), U8(4),
B(LdaCurrentContextSlot), U8(4),
B(Star), R(0),
B(LdaSmi), I8(1),
B(Star), R(1),
/* 59 E> */ B(StackCheck),
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
B(CreateBlockContext), U8(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(PushContext), 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(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(0),
B(StaCurrentContextSlot), U8(4),
B(LdaSmi), I8(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(TestEqual), R(1), 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(JumpIfFalse), U8(7),
B(LdaZero),
B(Star), R(1),
B(Jump), U8(8),
/* 43 S> */ B(LdaCurrentContextSlot), U8(4),
[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(Inc), 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
/* 43 E> */ B(StaCurrentContextSlot), U8(4),
B(LdaSmi), I8(1),
B(Star), R(2),
/* 35 S> */ B(LdaCurrentContextSlot), 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(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(LdaSmi), I8(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
/* 35 E> */ B(TestLessThan), R(7), 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(JumpIfFalse), U8(4),
B(Jump), U8(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(PopContext), 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(Jump), U8(77),
B(LdaSmi), I8(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(TestEqual), R(2), 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(JumpIfFalse), U8(54),
/* 17 E> */ B(StackCheck),
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
/* 48 S> */ B(LdaLookupGlobalSlot), U8(3), U8(4), 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(7),
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
B(LdaConstant), 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(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(LdaZero),
B(Star), 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(LdaSmi), I8(31),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[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(48),
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(Mov), R(7), R(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(Mov), R(8), R(10),
B(Mov), R(closure), R(11),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(9), U8(6),
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
/* 48 E> */ B(CallUndefinedReceiver1), R(7), R(8), 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(LdaZero),
B(Star), R(2),
B(LdaCurrentContextSlot), U8(4),
B(Star), R(0),
B(JumpLoop), U8(56), I8(1),
B(LdaSmi), I8(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
/* 59 E> */ B(TestEqual), R(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(JumpIfFalse), U8(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(PopContext), 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(Jump), 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(PopContext), R(6),
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
B(JumpLoop), U8(123), 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(PopContext), R(5),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
/* 61 S> */ B(Return),
]
constant pool: [
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
SCOPE_INFO_TYPE,
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_TYPE,
SCOPE_INFO_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
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["1"],
]
handlers: [
]
---
snippet: "
function f() {
for (let x = 0; x < 10; ++x) { (function() { return x; })(); }
}
f();
"
frame size: 6
parameter count: 1
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +00:00
bytecode array length: 106
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
/* 30 S> */ B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +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
B(Star), R(0),
B(LdaSmi), I8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(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
/* 78 E> */ B(StackCheck),
B(CreateBlockContext), U8(0),
B(PushContext), R(4),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Ldar), 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(StaCurrentContextSlot), U8(4),
B(LdaSmi), I8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(TestEqual), R(1), 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(JumpIfFalse), U8(7),
B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(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(Jump), U8(8),
/* 43 S> */ B(LdaCurrentContextSlot), U8(4),
[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(Inc), 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
/* 43 E> */ B(StaCurrentContextSlot), U8(4),
B(LdaSmi), I8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +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
/* 35 S> */ B(LdaCurrentContextSlot), U8(4),
B(Star), R(5),
B(LdaSmi), I8(10),
[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
/* 35 E> */ B(TestLessThan), R(5), 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(JumpIfFalse), U8(4),
B(Jump), U8(6),
B(PopContext), R(4),
B(Jump), U8(45),
B(LdaSmi), I8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(TestEqual), R(2), 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(JumpIfFalse), U8(22),
/* 17 E> */ B(StackCheck),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
/* 48 S> */ B(CreateClosure), U8(1), U8(0), 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(5),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
/* 74 E> */ B(CallUndefinedReceiver0), R(5), U8(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
B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +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
B(LdaCurrentContextSlot), U8(4),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), 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(JumpLoop), U8(24), I8(1),
B(LdaSmi), I8(1),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
/* 78 E> */ B(TestEqual), 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(JumpIfFalse), U8(6),
B(PopContext), R(4),
B(Jump), U8(7),
B(PopContext), R(4),
Replace Context::closure with Context::scope_info, allowing closure to die. There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-02 13:57:26 +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(LdaUndefined),
/* 80 S> */ B(Return),
]
constant pool: [
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_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
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
---
snippet: "
function f() {
for (let { x, y } = { x: 0, y: 3 }; y > 0; --y) { let z = x + y; }
}
f();
"
[destructuring] Get non-coercible message contents in runtime For desrtucturing assignments from null/undefined, we throw an error that references the destructuring object literal's property name, e.g. for var { x } = null; we report that we cannot destructure 'x' from null. Rather than calculating this property during bytecode generation (and including it in the bytecode as an argument to the type error constructor), we can calculate it at exception throwing time, by re-parsing the source in a similar way to the existing call site rendering. This slightly decreases bytecode size and slightly decreases the amount of work the bytecode compiler needs to do. In the future, it could also allow us to give more detailed error messages, as we now have access to the entire AST and are on the slow path anyway. Bug: v8:6499 Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72 Reviewed-on: https://chromium-review.googlesource.com/c/1396080 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58706}
2019-01-10 14:40:58 +00:00
frame size: 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
parameter count: 1
[destructuring] Get non-coercible message contents in runtime For desrtucturing assignments from null/undefined, we throw an error that references the destructuring object literal's property name, e.g. for var { x } = null; we report that we cannot destructure 'x' from null. Rather than calculating this property during bytecode generation (and including it in the bytecode as an argument to the type error constructor), we can calculate it at exception throwing time, by re-parsing the source in a similar way to the existing call site rendering. This slightly decreases bytecode size and slightly decreases the amount of work the bytecode compiler needs to do. In the future, it could also allow us to give more detailed error messages, as we now have access to the entire AST and are on the slow path anyway. Bug: v8:6499 Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72 Reviewed-on: https://chromium-review.googlesource.com/c/1396080 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58706}
2019-01-10 14:40:58 +00:00
bytecode array length: 53
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[parser] Don't desugar destructuring declarations. Emit a single destructuring assignment for destructuring declarations, which can be desugared by the bytecode generator. This allows us to remove destructuring desugaring from the parser (specifically, the pattern rewriter) entirely. The pattern "rewriter" is now only responsible for walking the destructuring pattern to declare variables, mark them assigned, and potentially rewrite scopes for the edge case of parameters with a sloppy eval. Note that since the rewriter is no longer rewriting, we have to flip the VariableProxy copying logic for var re-lookup, so that we now pass the new VariableProxy to the variable declaration and leave the original unresolved (rather than passing the original through and rewriting to a new unresolved VariableProxy). This change does have some effect on breakpoint locations, due to some of the available information changing between the parser and bytecode generator, however the new locations appear to be more consistent between assignments and declarations. Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82 Reviewed-on: https://chromium-review.googlesource.com/c/1382462 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58670}
2019-01-09 13:21:06 +00:00
/* 37 S> */ B(CreateObjectLiteral), U8(0), U8(0), U8(41),
B(JumpIfNull), U8(4),
[destructuring] Get non-coercible message contents in runtime For desrtucturing assignments from null/undefined, we throw an error that references the destructuring object literal's property name, e.g. for var { x } = null; we report that we cannot destructure 'x' from null. Rather than calculating this property during bytecode generation (and including it in the bytecode as an argument to the type error constructor), we can calculate it at exception throwing time, by re-parsing the source in a similar way to the existing call site rendering. This slightly decreases bytecode size and slightly decreases the amount of work the bytecode compiler needs to do. In the future, it could also allow us to give more detailed error messages, as we now have access to the entire AST and are on the slow path anyway. Bug: v8:6499 Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72 Reviewed-on: https://chromium-review.googlesource.com/c/1396080 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58706}
2019-01-10 14:40:58 +00:00
B(JumpIfNotUndefined), U8(7),
/* 26 E> */ B(CallRuntime), U16(Runtime::kThrowPatternAssignmentNonCoercible), R(0), U8(0),
[parser] Don't desugar destructuring declarations. Emit a single destructuring assignment for destructuring declarations, which can be desugared by the bytecode generator. This allows us to remove destructuring desugaring from the parser (specifically, the pattern rewriter) entirely. The pattern "rewriter" is now only responsible for walking the destructuring pattern to declare variables, mark them assigned, and potentially rewrite scopes for the edge case of parameters with a sloppy eval. Note that since the rewriter is no longer rewriting, we have to flip the VariableProxy copying logic for var re-lookup, so that we now pass the new VariableProxy to the variable declaration and leave the original unresolved (rather than passing the original through and rewriting to a new unresolved VariableProxy). This change does have some effect on breakpoint locations, due to some of the available information changing between the parser and bytecode generator, however the new locations appear to be more consistent between assignments and declarations. Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82 Reviewed-on: https://chromium-review.googlesource.com/c/1382462 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58670}
2019-01-09 13:21:06 +00:00
B(Star), R(3),
[destructuring] Get non-coercible message contents in runtime For desrtucturing assignments from null/undefined, we throw an error that references the destructuring object literal's property name, e.g. for var { x } = null; we report that we cannot destructure 'x' from null. Rather than calculating this property during bytecode generation (and including it in the bytecode as an argument to the type error constructor), we can calculate it at exception throwing time, by re-parsing the source in a similar way to the existing call site rendering. This slightly decreases bytecode size and slightly decreases the amount of work the bytecode compiler needs to do. In the future, it could also allow us to give more detailed error messages, as we now have access to the entire AST and are on the slow path anyway. Bug: v8:6499 Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72 Reviewed-on: https://chromium-review.googlesource.com/c/1396080 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58706}
2019-01-10 14:40:58 +00:00
/* 28 S> */ B(LdaNamedProperty), R(3), U8(1), U8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(0),
[destructuring] Get non-coercible message contents in runtime For desrtucturing assignments from null/undefined, we throw an error that references the destructuring object literal's property name, e.g. for var { x } = null; we report that we cannot destructure 'x' from null. Rather than calculating this property during bytecode generation (and including it in the bytecode as an argument to the type error constructor), we can calculate it at exception throwing time, by re-parsing the source in a similar way to the existing call site rendering. This slightly decreases bytecode size and slightly decreases the amount of work the bytecode compiler needs to do. In the future, it could also allow us to give more detailed error messages, as we now have access to the entire AST and are on the slow path anyway. Bug: v8:6499 Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72 Reviewed-on: https://chromium-review.googlesource.com/c/1396080 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58706}
2019-01-10 14:40:58 +00:00
/* 31 S> */ B(LdaNamedProperty), R(3), U8(2), U8(3),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(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
/* 55 S> */ B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 55 E> */ B(TestGreaterThan), R(1), U8(5),
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(JumpIfFalse), 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
/* 17 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 75 S> */ B(Ldar), R(1),
/* 77 E> */ B(Add), R(0), 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),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 62 S> */ B(Ldar), R(1),
B(Dec), U8(7),
B(Star), R(1),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(JumpLoop), U8(20), 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(LdaUndefined),
/* 84 S> */ B(Return),
]
constant pool: [
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
OBJECT_BOILERPLATE_DESCRIPTION_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
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["y"],
]
handlers: [
]
---
snippet: "
function* f() {
for (let x = 0; x < 10; ++x) { let y = x; }
}
f();
"
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
frame size: 5
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: 1
[ignition] Reduce generator switch boilerplate The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 11:19:51 +00:00
bytecode array length: 67
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(1),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Mov), R(closure), R(3),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), 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
/* 11 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 11 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(ResumeGenerator), R(0), R(0), U8(3),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Star), R(3),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(2), I8(0),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(3),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ B(Throw),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(3),
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
/* 62 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
/* 31 S> */ B(LdaZero),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(Star), R(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
/* 36 S> */ B(LdaSmi), I8(10),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
/* 36 E> */ B(TestLessThan), R(1), U8(0),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(JumpIfFalse), 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
/* 18 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 57 S> */ B(Mov), R(1), R(2),
/* 44 S> */ B(Ldar), R(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(Inc), U8(1),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(Star), R(1),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(JumpLoop), U8(17), 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(LdaUndefined),
/* 62 S> */ B(Return),
]
constant pool: [
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
Smi [22],
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
]
handlers: [
]
---
snippet: "
function* f() {
for (let x = 0; x < 10; ++x) yield x;
}
f();
"
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
frame size: 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
parameter count: 1
[ignition] Reduce generator switch boilerplate The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 11:19:51 +00:00
bytecode array length: 99
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Mov), R(closure), R(2),
B(Mov), R(this), R(3),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(2), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), 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
/* 11 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 11 E> */ B(SuspendGenerator), R(0), R(0), U8(2), U8(0),
B(ResumeGenerator), R(0), R(0), U8(2),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Star), R(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(2),
[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),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(2),
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
/* 56 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
/* 31 S> */ B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(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
/* 36 S> */ B(LdaSmi), I8(10),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 36 E> */ B(TestLessThan), R(1), U8(0),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(JumpIfFalse), U8(47),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 18 E> */ B(StackCheck),
[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
/* 47 S> */ B(LdaFalse),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(Star), R(3),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(1), R(2),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(2), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 47 E> */ B(SuspendGenerator), R(0), R(0), U8(2), U8(1),
B(ResumeGenerator), R(0), R(0), U8(2),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Star), R(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(SwitchOnSmiNoFeedback), U8(4), U8(2), I8(0),
B(Ldar), R(2),
[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
/* 47 E> */ B(Throw),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Ldar), R(2),
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
/* 56 S> */ B(Return),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 44 S> */ B(Ldar), R(1),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(1),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(JumpLoop), U8(49), 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(LdaUndefined),
/* 56 S> */ B(Return),
]
constant pool: [
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
Smi [22],
Smi [68],
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],
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
]
handlers: [
]
---
snippet: "
async function f() {
for (let x = 0; x < 10; ++x) { let y = x; }
}
f();
"
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
frame size: 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
parameter count: 1
Reland "[ignition] Skip binding dead labels" This is a reland of 35269f77f8a7fb5360717e2cb470a6ef1637944e Switches on an expression that unconditionally throws would have all their case statements dead, causing a DCHECK error in the SwitchBuilder. This fixes up the DCHECK to allow dead labels. Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org Bug: chromium:934166 Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4 Reviewed-on: https://chromium-review.googlesource.com/c/1494535 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59948}
2019-02-28 13:34:26 +00:00
bytecode array length: 81
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Mov), R(closure), R(3),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionEnter), R(3), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(0),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
/* 16 E> */ B(StackCheck),
B(Mov), R(context), R(3),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
/* 36 S> */ B(LdaZero),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(Star), R(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
/* 41 S> */ B(LdaSmi), I8(10),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
/* 41 E> */ B(TestLessThan), R(1), U8(0),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(JumpIfFalse), 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
/* 23 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 62 S> */ B(Mov), R(1), R(2),
/* 49 S> */ B(Ldar), R(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(Inc), U8(1),
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
B(Star), R(1),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(JumpLoop), U8(17), 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(LdaUndefined),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(5),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(6),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(0), R(4),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
/* 49 E> */ B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(4), U8(3),
[async] Improve async function handling. This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 05:54:39 +00:00
/* 67 S> */ B(Return),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(Star), R(4),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(CreateCatchContext), R(4), U8(0),
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
B(LdaTheHole),
B(SetPendingMessage),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Ldar), R(3),
B(PushContext), R(4),
[async] Improve async function handling. This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 05:54:39 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(6),
[inspector] reworked async stack instrumentation for async functions New intstrumentation consists of: - kAsyncFunctionSuspended when async function is suspended on await (called on each await), - kAsyncFunctionFinished when async function is finished. Old instrumentation was based on reusing async function promise. Using this promise produces couple side effects: - for any promise instrumentation we first need to check if it is special case for async function promise or not - it requires expensive reading from promise object. - we capture stack for async functions even if it does not contain awaits. - we do not properly cancel async task created for async function. New intsrumntation resolved all these problems as well as provide clear mapping between async task and generator which we can use later to fetch scope information for async functions on pause. R=dgozman@chromium.org,yangguo@chromium.org Bug: v8:7078 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ifdcec947d91e6e3d4d5f9029bc080a19b8e23d41 Reviewed-on: https://chromium-review.googlesource.com/1043096 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#53445}
2018-05-30 14:21:39 +00:00
B(LdaFalse),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(7),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(0), R(5),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionReject), R(5), 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
/* 67 S> */ B(Return),
]
constant pool: [
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_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: [
Reland "[ignition] Skip binding dead labels" This is a reland of 35269f77f8a7fb5360717e2cb470a6ef1637944e Switches on an expression that unconditionally throws would have all their case statements dead, causing a DCHECK error in the SwitchBuilder. This fixes up the DCHECK to allow dead labels. Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org Bug: chromium:934166 Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4 Reviewed-on: https://chromium-review.googlesource.com/c/1494535 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59948}
2019-02-28 13:34:26 +00:00
[16, 53, 53],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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() {
for (let x = 0; x < 10; ++x) await x;
}
f();
"
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
frame size: 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
parameter count: 1
Reland "[ignition] Skip binding dead labels" This is a reland of 35269f77f8a7fb5360717e2cb470a6ef1637944e Switches on an expression that unconditionally throws would have all their case statements dead, causing a DCHECK error in the SwitchBuilder. This fixes up the DCHECK to allow dead labels. Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org Bug: chromium:934166 Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4 Reviewed-on: https://chromium-review.googlesource.com/c/1494535 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59948}
2019-02-28 13:34:26 +00:00
bytecode array length: 117
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(SwitchOnGeneratorState), R(0), U8(0), U8(1),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Mov), R(closure), R(2),
B(Mov), R(this), R(3),
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionEnter), R(2), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(0),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
/* 16 E> */ B(StackCheck),
B(Mov), R(context), R(2),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
/* 36 S> */ B(LdaZero),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(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
/* 41 S> */ B(LdaSmi), I8(10),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 41 E> */ B(TestLessThan), R(1), U8(0),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(JumpIfFalse), U8(47),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 23 E> */ B(StackCheck),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 52 S> */ B(Mov), R(0), R(3),
B(Mov), R(1), R(4),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(3), U8(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 52 E> */ B(SuspendGenerator), R(0), R(0), U8(3), U8(0),
B(ResumeGenerator), R(0), R(0), U8(3),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(3),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
[async] Improve async function handling. This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 05:54:39 +00:00
B(Star), 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
B(LdaZero),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(TestReferenceEqual), R(4),
[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),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Ldar), R(3),
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),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
/* 49 S> */ B(Ldar), R(1),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(1),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Star), R(1),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(JumpLoop), U8(49), 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(LdaUndefined),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(4),
[async] Improve async function handling. This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 05:54:39 +00:00
B(LdaTrue),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(5),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(0), R(3),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
/* 49 E> */ B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(3), U8(3),
[async] Improve async function handling. This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 05:54:39 +00:00
/* 61 S> */ B(Return),
[ignition] Single-switch generator bytecode Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 13:51:38 +00:00
B(Star), R(3),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(CreateCatchContext), R(3), U8(1),
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
B(LdaTheHole),
B(SetPendingMessage),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Ldar), R(2),
B(PushContext), R(3),
[async] Improve async function handling. This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 05:54:39 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(5),
[inspector] reworked async stack instrumentation for async functions New intstrumentation consists of: - kAsyncFunctionSuspended when async function is suspended on await (called on each await), - kAsyncFunctionFinished when async function is finished. Old instrumentation was based on reusing async function promise. Using this promise produces couple side effects: - for any promise instrumentation we first need to check if it is special case for async function promise or not - it requires expensive reading from promise object. - we capture stack for async functions even if it does not contain awaits. - we do not properly cancel async task created for async function. New intsrumntation resolved all these problems as well as provide clear mapping between async task and generator which we can use later to fetch scope information for async functions on pause. R=dgozman@chromium.org,yangguo@chromium.org Bug: v8:7078 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ifdcec947d91e6e3d4d5f9029bc080a19b8e23d41 Reviewed-on: https://chromium-review.googlesource.com/1043096 Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#53445}
2018-05-30 14:21:39 +00:00
B(LdaTrue),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(Star), R(6),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(0), R(4),
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionReject), R(4), 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
/* 61 S> */ B(Return),
]
constant pool: [
[async] Introduce dedicated JSAsyncFunctionObject. This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 08:35:56 +00:00
Smi [46],
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_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: [
Reland "[ignition] Skip binding dead labels" This is a reland of 35269f77f8a7fb5360717e2cb470a6ef1637944e Switches on an expression that unconditionally throws would have all their case statements dead, causing a DCHECK error in the SwitchBuilder. This fixes up the DCHECK to allow dead labels. Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org Bug: chromium:934166 Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4 Reviewed-on: https://chromium-review.googlesource.com/c/1494535 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59948}
2019-02-28 13:34:26 +00:00
[20, 89, 89],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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