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

663 lines
21 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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 35 E> */ B(TestLessThan), R(1), U8(4),
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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), 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(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();
"
frame size: 14
parameter count: 1
bytecode array length: 168
bytecodes: [
B(CreateFunctionContext), U8(3),
B(PushContext), R(3),
B(Ldar), R(this),
B(StaCurrentContextSlot), U8(4),
B(CreateMappedArguments),
B(StaCurrentContextSlot), U8(6),
B(Ldar), R(new_target),
B(StaCurrentContextSlot), U8(5),
/* 10 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(4),
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),
B(PushContext), R(5),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(0),
B(StaCurrentContextSlot), U8(4),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(TestEqual), R(1), 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(JumpIfFalse), U8(7),
B(LdaZero),
B(Star), R(1),
B(Jump), U8(8),
/* 43 S> */ B(LdaCurrentContextSlot), U8(4),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), 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
/* 43 E> */ B(StaCurrentContextSlot), U8(4),
B(LdaSmi), I8(1),
B(Star), R(2),
/* 35 S> */ B(LdaCurrentContextSlot), U8(4),
B(Star), R(6),
B(LdaSmi), I8(10),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 35 E> */ B(TestLessThan), R(6), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(6),
B(PopContext), R(5),
B(Jump), U8(77),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(TestEqual), R(2), 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(54),
/* 17 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 48 S> */ B(LdaLookupGlobalSlot), U8(2), U8(10), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(6),
B(LdaConstant), U8(3),
B(Star), R(7),
B(LdaZero),
B(Star), R(11),
B(LdaSmi), I8(31),
B(Star), R(12),
B(LdaSmi), I8(48),
B(Star), R(13),
B(Mov), R(6), R(8),
B(Mov), R(7), R(9),
B(Mov), R(closure), R(10),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(8), U8(6),
B(Star), R(6),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 48 E> */ B(CallUndefinedReceiver1), R(6), R(7), 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(LdaZero),
B(Star), R(2),
B(LdaCurrentContextSlot), U8(4),
B(Star), R(0),
B(JumpLoop), U8(56), I8(1),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 59 E> */ B(TestEqual), R(2), U8(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(PopContext), R(5),
B(Jump), U8(7),
B(PopContext), R(5),
B(JumpLoop), U8(125), I8(0),
B(PopContext), R(4),
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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(TestEqual), R(2), 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(JumpIfFalse), U8(7),
B(LdaZero),
B(Star), R(2),
B(Jump), U8(8),
/* 43 S> */ B(LdaCurrentContextSlot), U8(4),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), 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
/* 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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 35 E> */ B(TestLessThan), R(5), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(4),
B(Jump), U8(6),
B(PopContext), R(4),
B(Jump), U8(45),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
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(22),
/* 17 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 48 S> */ B(CreateClosure), U8(1), U8(10), 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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 74 E> */ B(CallUndefinedReceiver0), R(5), 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(LdaZero),
B(Star), R(3),
B(LdaCurrentContextSlot), U8(4),
B(Star), R(1),
B(JumpLoop), U8(24), I8(1),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 78 E> */ B(TestEqual), R(3), U8(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(CreateObjectLiteral), U8(0), U8(4), 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),
[parser] Provide better error when incorrectly using await Before we try to do ASI and fail with a generic error, we special case for the await token in the failure case. Bug: v8:6572, v8:6513 Change-Id: Ia050c98b5a5b20bc326f429a367635b8553e4112 Reviewed-on: https://chromium-review.googlesource.com/582210 Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#46885}
2017-07-25 17:33:52 +00:00
B(LdaSmi), I8(63),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 37 S> */ B(LdaNamedProperty), R(3), U8(1), 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(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 37 S> */ B(LdaNamedProperty), R(3), U8(2), 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(2),
/* 55 S> */ B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 55 E> */ B(TestGreaterThan), R(2), U8(11),
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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 77 E> */ B(Add), R(1), U8(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(0),
/* 62 S> */ B(Ldar), R(2),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Dec), U8(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(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();
"
[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
frame size: 7
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 1
[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
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: [
[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(new_target), 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(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
[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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(3), U8(1),
B(PushContext), R(5),
B(RestoreGeneratorState), R(3),
B(Star), R(4),
[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),
[compiler] Drive optimizations with feedback vector (reland) For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. This is a reland of https://chromium-review.googlesource.com/c/509716 Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe Reviewed-on: https://chromium-review.googlesource.com/535460 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45997}
2017-06-15 14:53:38 +00:00
B(LdaSmi), I8(81),
[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),
B(CallRuntime), U16(Runtime::kAbort), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-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(4),
B(Mov), R(closure), R(5),
B(Mov), R(this), R(6),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(5), U8(2),
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] 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(Star), R(3),
/* 11 E> */ B(SuspendGenerator), R(3), R(0), U8(5), 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),
[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(RestoreGeneratorRegisters), R(3), R(0), 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(LdaSmi), I8(-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(4),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(3), U8(1),
B(Star), R(5),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(3), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(1), U8(2), I8(0),
[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),
[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),
[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),
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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 36 E> */ B(TestLessThan), R(1), U8(4),
[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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), U8(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(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: [
[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
Smi [38],
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] 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
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
[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
bytecode array length: 170
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[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(new_target), R(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
[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(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(2), I8(0),
[compiler] Drive optimizations with feedback vector (reland) For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. This is a reland of https://chromium-review.googlesource.com/c/509716 Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe Reviewed-on: https://chromium-review.googlesource.com/535460 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45997}
2017-06-15 14:53:38 +00:00
B(LdaSmi), I8(81),
[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(CallRuntime), U16(Runtime::kAbort), R(4), 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(LdaSmi), I8(-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(3),
B(Mov), R(closure), R(4),
B(Mov), R(this), R(5),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(4), U8(2),
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] 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(Star), R(2),
/* 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
/* 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
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),
[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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(2), U8(1),
B(Star), R(4),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(2), I8(0),
[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),
[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),
[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),
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),
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
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),
[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
/* 31 E> */ B(TestEqualStrictNoFeedback), 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(JumpIfTrue), U8(11),
[compiler] Drive optimizations with feedback vector (reland) For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. This is a reland of https://chromium-review.googlesource.com/c/509716 Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe Reviewed-on: https://chromium-review.googlesource.com/535460 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45997}
2017-06-15 14:53:38 +00:00
B(LdaSmi), I8(81),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(4),
[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(CallRuntime), U16(Runtime::kAbort), R(4), U8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 36 S> */ B(LdaSmi), I8(10),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 36 E> */ B(TestLessThan), R(0), U8(4),
[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),
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(Mov), R(0), R(4),
[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(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(4), U8(2),
[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(SuspendGenerator), R(2), R(0), U8(4), 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),
[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(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),
[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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(2), U8(1),
B(Star), R(4),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(2), U8(1),
B(SwitchOnSmiNoFeedback), U8(5), U8(2), I8(0),
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
/* 47 E> */ B(Throw),
[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),
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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), U8(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(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(JumpLoop), U8(79), 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: [
[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
Smi [38],
Smi [69],
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],
[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
Smi [43],
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();
"
[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
frame size: 13
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 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
bytecode array length: 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
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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(4),
[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(CallJSRuntime), U8(%async_function_promise_create), R(4), U8(1),
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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 41 E> */ B(TestLessThan), R(1), U8(4),
[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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), U8(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(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),
[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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[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(10),
B(Mov), R(3), R(9),
/* 49 E> */ B(CallJSRuntime), U8(%promise_resolve), R(8), 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(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),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(59),
B(Jump), U8(45),
[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(LdaUndefined),
[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(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(LdaImmutableCurrentContextSlot), U8(4),
[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(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaFalse),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(Star), R(12),
B(Mov), R(3), R(10),
B(CallJSRuntime), U8(%promise_internal_reject), R(9), U8(4),
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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(14),
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(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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[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(7),
B(Mov), R(3), R(8),
B(CallJSRuntime), U8(%async_function_promise_release), R(7), U8(2),
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: [
[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
[13, 105, 111],
[16, 60, 62],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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();
"
[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
frame size: 14
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 1
[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
bytecode array length: 264
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[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(new_target), 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(Ldar), R(new_target),
[Interpreter] Handle various generator intrinsics We can avoid some runtime calls by implementing intrinsics. BUG= Review-Url: https://codereview.chromium.org/2889973002 Cr-Commit-Position: refs/heads/master@{#45418}
2017-05-19 09:27:25 +00:00
B(JumpIfUndefined), U8(25),
[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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(3), U8(1),
B(PushContext), R(5),
B(RestoreGeneratorState), R(3),
B(Star), R(4),
[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),
[compiler] Drive optimizations with feedback vector (reland) For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. This is a reland of https://chromium-review.googlesource.com/c/509716 Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe Reviewed-on: https://chromium-review.googlesource.com/535460 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45997}
2017-06-15 14:53:38 +00:00
B(LdaSmi), I8(81),
[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),
B(CallRuntime), U16(Runtime::kAbort), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-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(4),
B(Mov), R(closure), R(5),
B(Mov), R(this), R(6),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(5), U8(2),
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),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(Star), R(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(CallJSRuntime), U8(%async_function_promise_create), R(5), U8(1),
B(Star), R(2),
B(Mov), R(1), R(3),
B(Mov), R(context), R(7),
B(Mov), R(context), R(8),
/* 36 S> */ B(LdaZero),
B(Star), R(0),
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(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),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
/* 36 E> */ B(TestEqualStrictNoFeedback), R(4),
[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(JumpIfTrue), U8(11),
[compiler] Drive optimizations with feedback vector (reland) For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. This is a reland of https://chromium-review.googlesource.com/c/509716 Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe Reviewed-on: https://chromium-review.googlesource.com/535460 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45997}
2017-06-15 14:53:38 +00:00
B(LdaSmi), I8(81),
[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(9),
B(CallRuntime), U16(Runtime::kAbort), R(9), U8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 41 S> */ B(LdaSmi), I8(10),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 41 E> */ B(TestLessThan), R(0), U8(4),
[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] 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
/* 52 S> */ B(Mov), R(3), R(9),
B(Mov), R(0), R(10),
B(Mov), R(2), R(11),
B(CallJSRuntime), U8(%async_function_await_uncaught), R(9), U8(3),
[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(SuspendGenerator), R(3), R(0), U8(9), 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),
[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(RestoreGeneratorRegisters), R(3), R(0), 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(LdaSmi), I8(-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(4),
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(3), 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 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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(3), 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(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[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(TestEqualStrictNoFeedback), R(10),
[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] 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(Ldar), 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
/* 52 E> */ 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),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
B(Inc), U8(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(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(JumpLoop), U8(82), 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),
[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(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
[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(11),
B(Mov), R(2), R(10),
/* 49 E> */ B(CallJSRuntime), U8(%promise_resolve), R(9), U8(3),
[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(5),
B(Mov), R(2), R(6),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(59),
B(Jump), U8(45),
[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(9),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Ldar), R(closure),
[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(CreateCatchContext), R(9), U8(2), 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(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[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(8),
B(PushContext), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
[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(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(LdaImmutableCurrentContextSlot), U8(4),
[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(12),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(LdaFalse),
[parser] avoid for-loop desugaring unless loop var may be captured In https://chromium-review.googlesource.com/c/472247/, I avoided running DesugarLexicalBindingsInForStatement() if there were no lexical loop variables, the function was not resumable, and the variables are not captured by eval or a function declaration. I think it's now possible to limit this further, and only do the more extensive desugaring if there's a function declaration / eval() call in the loop body. `yield` and `await` are not an issue as those loop variables are written to the register file and not lost. This change just removes the `is_resumable()` condition. If it passes tests, I think it's safe. BUG=v8:4762, v8:5460, v8:6579 Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a Reviewed-on: https://chromium-review.googlesource.com/563587 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46536}
2017-07-07 20:48:16 +00:00
B(Star), R(13),
B(Mov), R(2), R(11),
B(CallJSRuntime), U8(%promise_internal_reject), R(10), U8(4),
B(PopContext), R(9),
[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(5),
B(Mov), R(2), 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(14),
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(5),
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(6),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(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(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(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(7),
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(LdaUndefined),
[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),
B(Mov), R(2), R(9),
B(CallJSRuntime), U8(%async_function_promise_release), R(8), U8(2),
B(Ldar), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(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(5),
[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),
[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
/* 61 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(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(ReThrow),
B(LdaUndefined),
/* 61 S> */ B(Return),
]
constant pool: [
[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
Smi [51],
[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
Smi [46],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
[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
[62, 219, 225],
[65, 174, 176],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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