AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
3d4a982685
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.

631 lines
20 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),
B(Star), R(1),
/* 35 S> */ 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(1), 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),
/* 56 S> */ B(Mov), R(1), R(0),
/* 43 S> */ B(Ldar), R(0),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(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
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(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
bytecode array length: 168
bytecodes: [
B(CreateFunctionContext), 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),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PushContext), R(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),
B(Ldar), R(closure),
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(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),
[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
/* 48 S> */ B(LdaLookupGlobalSlot), U8(2), U8(6), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(7),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaConstant), U8(3),
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),
/* 48 E> */ B(CallUndefinedReceiver1), R(7), R(8), 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),
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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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(125), 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: [
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
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
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: 108
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
B(Star), R(0),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(2),
/* 78 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(4),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(1),
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(2), 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(2),
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(3),
/* 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),
[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(3), 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),
[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
/* 48 S> */ B(CreateClosure), U8(1), U8(6), 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),
[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
/* 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),
B(Star), R(3),
B(LdaCurrentContextSlot), U8(4),
B(Star), R(1),
B(JumpLoop), U8(24), 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
/* 78 E> */ B(TestEqual), R(3), U8(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(JumpIfFalse), U8(6),
B(PopContext), R(4),
B(Jump), U8(7),
B(PopContext), R(4),
B(JumpLoop), U8(93), I8(0),
B(LdaUndefined),
/* 80 S> */ B(Return),
]
constant pool: [
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
---
snippet: "
function f() {
for (let { x, y } = { x: 0, y: 3 }; y > 0; --y) { let z = x + y; }
}
f();
"
frame size: 6
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: 68
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[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(CreateObjectLiteral), U8(0), U8(0), U8(41), 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(Mov), R(4), R(3),
B(Ldar), R(3),
B(JumpIfUndefined), U8(6),
B(Ldar), R(3),
B(JumpIfNotNull), U8(16),
[bigint] Introduce ToNumeric conversion. This introduces a ToNumeric conversion to the runtime and interpreter. ToNumeric behaves like ToNumber, except that it also lets BigInts pass. Bug: v8:6791 Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7 Reviewed-on: https://chromium-review.googlesource.com/707013 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48440}
2017-10-10 16:00:31 +00:00
B(LdaSmi), I8(68),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(4),
B(LdaConstant), U8(1),
B(Star), R(5),
B(CallRuntime), U16(Runtime::kNewTypeError), R(4), U8(2),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
/* 28 E> */ B(Throw),
[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
/* 37 S> */ B(LdaNamedProperty), R(3), U8(1), 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(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
/* 37 S> */ B(LdaNamedProperty), R(3), U8(2), U8(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(Star), R(2),
/* 55 S> */ B(LdaZero),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 55 E> */ B(TestGreaterThan), R(2), U8(7),
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),
[inspector] moved var initialization break location before init expression (reland) This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294 Reviewed-on: https://chromium-review.googlesource.com/518116 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45598}
2017-05-30 12:25:55 +00:00
/* 75 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
/* 77 E> */ B(Add), R(1), U8(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(0),
/* 62 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(Dec), 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(Star), R(2),
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: [
FIXED_ARRAY_TYPE,
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();
"
[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: 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
parameter count: 1
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
bytecode array length: 96
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(2),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfUndefined), U8(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(2), U8(1),
B(PushContext), R(4),
B(RestoreGeneratorState), R(2),
B(Star), R(3),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
[codegen] Delete unused StringCharLoadGenerator Bug: v8:6921 Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c Reviewed-on: https://chromium-review.googlesource.com/718697 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48545}
2017-10-13 12:21:40 +00:00
B(Abort), U8(42),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(-2),
B(Star), R(3),
B(Mov), R(closure), R(4),
B(Mov), R(this), R(5),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(4), U8(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
B(Star), R(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 11 E> */ B(StackCheck),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 11 E> */ B(SuspendGenerator), R(2), R(0), U8(4), U8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 62 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(2), R(0), U8(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(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(3),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(2), U8(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(Star), R(4),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(2), I8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(4),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(4),
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),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(1),
/* 36 S> */ 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
/* 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),
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
/* 57 S> */ B(Mov), R(1), R(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
/* 44 S> */ B(Ldar), R(0),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(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(Star), R(1),
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: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [29],
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();
"
[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: 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
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
bytecode array length: 151
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(1),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfUndefined), U8(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(1), U8(1),
B(PushContext), R(3),
B(RestoreGeneratorState), R(1),
B(Star), R(2),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(2), I8(0),
[codegen] Delete unused StringCharLoadGenerator Bug: v8:6921 Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c Reviewed-on: https://chromium-review.googlesource.com/718697 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48545}
2017-10-13 12:21:40 +00:00
B(Abort), U8(42),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(-2),
B(Star), R(2),
B(Mov), R(closure), R(3),
B(Mov), R(this), R(4),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(3), U8(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
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
/* 11 E> */ B(StackCheck),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 11 E> */ B(SuspendGenerator), R(1), R(0), U8(3), 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
/* 56 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(1), R(0), 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(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(2),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(1), U8(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(Star), R(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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(1), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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),
[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),
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),
[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(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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
B(SwitchOnSmiNoFeedback), U8(4), U8(1), I8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 31 E> */ B(TestEqualStrictNoFeedback), R(2),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfTrue), U8(4),
[codegen] Delete unused StringCharLoadGenerator Bug: v8:6921 Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c Reviewed-on: https://chromium-review.googlesource.com/718697 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48545}
2017-10-13 12:21:40 +00:00
B(Abort), U8(42),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 36 S> */ 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
/* 36 E> */ B(TestLessThan), R(0), U8(0),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator Remove need for shuffling of accumulator and operand registers when suspending a generator BUG=v8:6351 TBR=bmeurer@chromium.org Change-Id: I372509adc03b9781716412b809639554fe16e372 Reviewed-on: https://chromium-review.googlesource.com/578377 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46883}
2017-07-25 18:37:36 +00:00
B(JumpIfFalse), U8(56),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[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(4),
B(Mov), R(0), R(3),
B(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(3), U8(2),
B(SuspendGenerator), R(1), R(0), U8(3), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 56 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(1), R(0), 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(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(2),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(1), U8(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(Star), R(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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(1), U8(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(SwitchOnSmiNoFeedback), U8(5), U8(2), I8(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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
/* 47 E> */ B(Throw),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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
/* 56 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
/* 44 S> */ B(Ldar), R(0),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(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(Star), R(0),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpLoop), U8(72), 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: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [29],
Smi [60],
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],
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [36],
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();
"
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
frame size: 12
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 1
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
bytecode array length: 137
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 16 E> */ B(StackCheck),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(CallJSRuntime), U8(%async_function_promise_create), R(0), U8(0),
[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),
B(Mov), R(context), R(6),
B(Mov), R(context), R(7),
/* 36 S> */ B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(1),
/* 41 S> */ 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
/* 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),
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
/* 62 S> */ B(Mov), R(1), R(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
/* 49 S> */ B(Ldar), R(0),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(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(Star), R(1),
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),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(9),
B(Mov), R(3), R(8),
/* 49 E> */ B(CallJSRuntime), U8(%promise_resolve), R(8), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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),
B(Mov), R(3), R(5),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Jump), U8(58),
B(Jump), U8(42),
[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(8),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
[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(CreateCatchContext), R(8), U8(0), U8(1),
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(LdaTheHole),
B(SetPendingMessage),
[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(Ldar), R(7),
B(PushContext), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaFalse),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(11),
B(Mov), R(3), R(9),
B(CallJSRuntime), U8(%promise_internal_reject), R(9), U8(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
B(PopContext), R(8),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[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),
B(Mov), R(3), R(5),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(5),
[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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[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(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(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(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(LdaTheHole),
B(SetPendingMessage),
[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(6),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(CallJSRuntime), U8(%async_function_promise_release), R(3), U8(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(Ldar), R(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[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(Ldar), R(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(Jump), U8(8),
[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(Ldar), 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
/* 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(Ldar), 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(ReThrow),
B(LdaUndefined),
/* 67 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Smi [9],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
[10, 96, 104],
[13, 54, 56],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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();
"
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
frame size: 12
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 1
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
bytecode array length: 231
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(1),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfUndefined), U8(18),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(1), U8(1),
B(PushContext), R(4),
B(RestoreGeneratorState), R(1),
B(Star), R(3),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(1), I8(0),
[codegen] Delete unused StringCharLoadGenerator Bug: v8:6921 Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c Reviewed-on: https://chromium-review.googlesource.com/718697 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48545}
2017-10-13 12:21:40 +00:00
B(Abort), U8(42),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(-2),
B(Star), R(3),
B(Mov), R(closure), R(4),
B(Mov), R(this), R(5),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(4), U8(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
B(Star), R(1),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 16 E> */ B(StackCheck),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(CallJSRuntime), U8(%async_function_promise_create), R(0), U8(0),
[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(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(Mov), R(context), R(6),
[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(Mov), R(context), R(7),
/* 36 S> */ B(LdaZero),
B(Star), R(0),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(3),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(1), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
/* 36 E> */ B(TestEqualStrictNoFeedback), R(3),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpIfTrue), U8(4),
[codegen] Delete unused StringCharLoadGenerator Bug: v8:6921 Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c Reviewed-on: https://chromium-review.googlesource.com/718697 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48545}
2017-10-13 12:21:40 +00:00
B(Abort), U8(42),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 41 S> */ 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
/* 41 E> */ B(TestLessThan), R(0), U8(0),
[interpreter] make `suspend_id` an immediate operand to SuspendGenerator Remove need for shuffling of accumulator and operand registers when suspending a generator BUG=v8:6351 TBR=bmeurer@chromium.org Change-Id: I372509adc03b9781716412b809639554fe16e372 Reviewed-on: https://chromium-review.googlesource.com/578377 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46883}
2017-07-25 18:37:36 +00:00
B(JumpIfFalse), U8(59),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
[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
/* 52 S> */ B(Mov), R(1), R(8),
B(Mov), R(0), R(9),
B(Mov), R(2), R(10),
B(CallJSRuntime), U8(%async_function_await_uncaught), R(8), U8(3),
B(SuspendGenerator), R(1), R(0), U8(8), 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
/* 61 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(RestoreGeneratorRegisters), R(1), R(0), 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(LdaSmi), I8(-2),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(3),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(1), U8(1),
B(Star), R(8),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(1), U8(1),
[interpreter] refactor BuildGeneratorSuspend/Resume into BuildSuspendPoint Simplify the model for generating Awaits, because the resume point is always immediately following the suspend point, and registers used are always the same for both operations. Includes a minor refactoring of BytecodeGenerator::VisitYield() to perform iterator result creation before the SuspendGenerator bytecode, rather than between SuspendGenerator and Return. This adds a small number of bytecodes for each yield. BUG=v8:2355, v8:5855 Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089 Reviewed-on: https://chromium-review.googlesource.com/576286 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46820}
2017-07-20 12:35:28 +00:00
B(Star), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(TestEqualStrictNoFeedback), R(9),
[async-await] desugar Await in BytecodeGenerator This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
2017-07-13 13:53:13 +00:00
B(JumpIfTrue), U8(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(8),
Reland "[async-iteration] implement spec-change to `yield` in async generators" Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500 Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
B(ReThrow),
[parser] avoid 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
/* 49 S> */ B(Ldar), R(0),
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
B(Inc), U8(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(Star), R(0),
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
B(JumpLoop), U8(75), 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),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(9),
B(Mov), R(2), R(8),
/* 49 E> */ B(CallJSRuntime), U8(%promise_resolve), R(8), U8(2),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(4),
B(Mov), R(2), R(5),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Jump), U8(58),
B(Jump), U8(42),
[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(8),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(8), U8(2), U8(3),
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(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(7),
B(PushContext), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(10),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(LdaFalse),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(Star), R(11),
B(Mov), R(2), R(9),
B(CallJSRuntime), U8(%promise_internal_reject), R(9), U8(3),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(PopContext), R(8),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(4),
B(Mov), R(2), R(5),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Jump), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[ignition] Always write the deferred command result register For deferred commands (such as in try-finally), some deferred commands save and restore the accumulator using a result register (e.g. return, throw, rethrow), while others don't (e.g. break, continue, fall-through). However, conditionally reading this result register that may not ever be written caused it to be considered live from the start of the function, as far as the liveness analysis could statically tell. Now, we write the result register for all deferred commands, including the fall-through. As a micro-optimization, we re-use the Smi command tokeen to clobber the result, rather than emitting an LdaUndefined. Bug: chromium:758472 Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b Reviewed-on: https://chromium-review.googlesource.com/635592 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:04:42 +00:00
B(Star), R(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(4),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(Jump), U8(8),
[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(5),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(LdaSmi), I8(1),
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(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Star), R(6),
[Interpreter] Make CallJSRuntime implicitly use undefined reciever. JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-06 22:48:36 +00:00
B(CallJSRuntime), U8(%async_function_promise_release), R(2), U8(1),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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(SetPendingMessage),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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(SwitchOnSmiNoFeedback), U8(4), U8(2), I8(0),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(Jump), U8(8),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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
/* 61 S> */ B(Return),
[Interpreter] Remove new.target from fixed frame slot. Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 15:16:31 +00:00
B(Ldar), R(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(ReThrow),
B(LdaUndefined),
/* 61 S> */ B(Return),
]
constant pool: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
Smi [38],
Smi [39],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Smi [9],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
Introduce an Abort bytecode and turbofan operator. The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 11:46:07 +00:00
[46, 190, 198],
[49, 148, 150],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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