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

1518 lines
56 KiB
Plaintext
Raw Normal View History

[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
test function name: f
---
snippet: "
function f(arr) {
for (let x of arr) { let y = x; }
}
f([1, 2, 3]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 16
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
bytecode array length: 260
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
/* 10 E> */ B(StackCheck),
B(LdaZero),
B(Star), R(6),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(context), R(13),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 34 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(15),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(15), R(arg0), U8(6),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(arg0), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(4),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 29 S> */ B(LdaNamedProperty), R(4), U8(1), U8(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(14),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(14), R(4), U8(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(5),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 29 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(5), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(2), U8(12),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(JumpIfToBooleanTrue), U8(28),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(3), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(7),
B(LdaSmi), I8(2),
B(Star), R(6),
B(Mov), R(7), R(3),
/* 20 E> */ B(StackCheck),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(Mov), R(3), R(1),
/* 49 S> */ B(Mov), R(1), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
B(Star), R(6),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(JumpLoop), U8(53), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
/* 49 E> */ B(CreateCatchContext), R(14), U8(4), U8(5),
B(PushContext), R(14),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(6), U8(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(6),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kReThrow), R(15), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
B(Star), R(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(6), U8(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(4), U8(6), U8(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(8),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
B(Jump), U8(93),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(6), U8(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(61),
B(Ldar), R(8),
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(14),
B(CallRuntime), U16(Runtime::kNewTypeError), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(13),
B(Mov), R(8), R(14),
B(Mov), R(4), R(15),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(14), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(20),
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(14), U8(4), U8(8),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(13),
B(PushContext), R(14),
B(PopContext), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(8), R(13),
B(Mov), R(4), R(14),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(9),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(9), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(9), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(10),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 54 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
]
handlers: [
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
[7, 124, 130],
[10, 88, 90],
[190, 200, 202],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function f(arr) {
for (let x of arr) { eval('1'); }
}
f([1, 2, 3]);
"
frame size: 22
parameter count: 2
[interpreter] Avoid redundant {PopContext} instructions. This avoids emitting redundant {PopContext} bytecode instructions when non-local control-flow leaves the method body. It also folds multiple such {PopContext} instructions into one, in case several scoping levels are crossed at one. Only the expected context of the target of a local control-flow transfer matters. R=rmcilroy@chromium.org TEST=debugger/regress/regress-crbug-724858 BUG=chromium:724858 Change-Id: Id4a47ae9fea25e75ae1af13619720b16a3975edf Reviewed-on: https://chromium-review.googlesource.com/512545 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45507}
2017-05-24 08:08:21 +00:00
bytecode array length: 343
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
B(CreateFunctionContext), U8(4),
B(PushContext), R(7),
B(Ldar), R(this),
B(StaCurrentContextSlot), U8(5),
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
B(CreateMappedArguments),
B(StaCurrentContextSlot), U8(7),
B(Ldar), R(new_target),
B(StaCurrentContextSlot), U8(6),
/* 10 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(8),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(LdaZero),
B(Star), R(3),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), 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(Mov), R(context), R(12),
/* 34 S> */ B(LdaContextSlot), R(8), U8(4), U8(0),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(13), U8(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(Star), R(14),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(14), R(13), 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(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 29 S> */ B(LdaNamedProperty), R(1), U8(2), U8(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(13), R(1), U8(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(2),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 29 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(2), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(2), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(2), U8(3), 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(JumpIfToBooleanTrue), U8(78),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(2), U8(4), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(4),
B(LdaSmi), I8(2),
B(Star), R(3),
B(Mov), R(4), R(0),
/* 20 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PushContext), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(4),
B(StaCurrentContextSlot), U8(4),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 41 S> */ B(LdaLookupGlobalSlot), U8(6), U8(18), 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(14),
B(LdaConstant), U8(7),
B(Star), R(15),
B(LdaZero),
B(Star), R(19),
B(LdaSmi), I8(37),
B(Star), R(20),
B(LdaSmi), I8(41),
B(Star), R(21),
B(Mov), R(14), R(16),
B(Mov), R(15), R(17),
B(Mov), R(closure), R(18),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(16), U8(6),
B(Star), R(14),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 41 E> */ B(CallUndefinedReceiver1), R(14), R(15), U8(16),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(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(LdaZero),
B(Star), R(3),
B(JumpLoop), U8(103), I8(0),
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(13),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(13), U8(8), U8(9),
B(PushContext), R(13),
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(3), U8(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(14),
B(CallRuntime), U16(Runtime::kReThrow), R(14), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(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(Jump), U8(7),
B(Star), R(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(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(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(3), U8(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(1), U8(10), U8(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(5),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
B(Jump), U8(93),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(3), U8(25),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(61),
B(Ldar), R(5),
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kNewTypeError), R(12), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(12),
B(Mov), R(5), R(13),
B(Mov), R(1), R(14),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(13), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(20),
B(Star), R(13),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(13), U8(8), U8(12),
B(Star), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(12),
B(PushContext), R(13),
B(PopContext), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(5), R(12),
B(Mov), R(1), R(13),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(12), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(6),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(9),
[interpreter] Avoid redundant {PopContext} instructions. This avoids emitting redundant {PopContext} bytecode instructions when non-local control-flow leaves the method body. It also folds multiple such {PopContext} instructions into one, in case several scoping levels are crossed at one. Only the expected context of the target of a local control-flow transfer matters. R=rmcilroy@chromium.org TEST=debugger/regress/regress-crbug-724858 BUG=chromium:724858 Change-Id: Id4a47ae9fea25e75ae1af13619720b16a3975edf Reviewed-on: https://chromium-review.googlesource.com/512545 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45507}
2017-05-24 08:08:21 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(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(ReThrow),
B(PopContext), R(8),
B(LdaUndefined),
/* 54 S> */ B(Return),
]
constant pool: [
FIXED_ARRAY_TYPE,
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["1"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
]
handlers: [
[35, 205, 211],
[38, 169, 171],
[271, 281, 283],
]
---
snippet: "
function f(arr) {
for (let x of arr) { (function() { return x; })(); }
}
f([1, 2, 3]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 14
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
bytecode array length: 278
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
/* 10 E> */ B(StackCheck),
B(LdaZero),
B(Star), R(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(context), R(11),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 34 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(13), R(arg0), U8(6),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(arg0), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 29 S> */ B(LdaNamedProperty), R(2), U8(1), U8(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(12), R(2), U8(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(3),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 29 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(3), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(3), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(3), U8(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(JumpIfToBooleanTrue), U8(46),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(3), U8(3), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(5),
B(LdaSmi), I8(2),
B(Star), R(4),
B(Mov), R(5), R(1),
/* 20 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(Ldar), R(5),
B(StaCurrentContextSlot), U8(4),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 41 S> */ B(CreateClosure), U8(5), U8(18), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(13),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 67 E> */ B(CallUndefinedReceiver0), R(13), U8(16),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
B(Star), R(4),
B(JumpLoop), U8(71), I8(0),
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(12),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(12), U8(6), U8(7),
B(PushContext), R(12),
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(4), U8(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(4),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(13),
B(CallRuntime), U16(Runtime::kReThrow), R(13), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
B(Star), R(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(4), U8(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(2), U8(8), U8(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(6),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
B(Jump), U8(93),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(4), U8(24),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(61),
B(Ldar), R(6),
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(12),
B(CallRuntime), U16(Runtime::kNewTypeError), R(11), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(11),
B(Mov), R(6), R(12),
B(Mov), R(2), R(13),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(12), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(20),
B(Star), R(12),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(12), U8(6), U8(10),
B(Star), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(11),
B(PushContext), R(12),
B(PopContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(6), R(11),
B(Mov), R(2), R(12),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(11), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(7),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(7), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(7), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(10),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(8),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 73 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
]
handlers: [
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
[7, 142, 148],
[10, 106, 108],
[208, 218, 220],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function f(arr) {
for (let { x, y } of arr) { let z = x + y; }
}
f([{ x: 0, y: 3 }, { x: 1, y: 9 }, { x: -12, y: 17 }]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 19
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
bytecode array length: 298
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
/* 10 E> */ B(StackCheck),
B(LdaZero),
B(Star), R(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Mov), R(context), R(16),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 41 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(18),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(18), R(arg0), U8(6),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(arg0), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
B(Star), R(7),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 36 S> */ B(LdaNamedProperty), R(7), U8(1), U8(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(17), 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(Star), R(8),
[inspector] removed call break location from for-of loop There are two break locations at the same source location by desugaring: - call iterator.next, - before variable assignment. Additionally location for for..of loops is moved from before "of" to before each variable expression. We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios: - when this call is reached by stepOver or stepInto from previous line, - when this call is reached because of breakpoint at current line. BUG=v8:6425 R=dgozman@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2893313002 Cr-Commit-Position: refs/heads/master@{#45509}
2017-05-24 12:12:53 +00:00
/* 36 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(8), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(8), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(8), U8(2), U8(12),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(JumpIfToBooleanTrue), U8(66),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(8), U8(3), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(10),
B(LdaSmi), I8(2),
B(Star), R(9),
B(Mov), R(10), R(5),
/* 20 E> */ B(StackCheck),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(Mov), R(5), R(6),
[ignition] Fix register flushing performance issue In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
2017-06-09 09:26:27 +00:00
B(Ldar), R(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfUndefined), U8(6),
B(Ldar), R(6),
B(JumpIfNotNull), U8(16),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
B(LdaSmi), I8(62),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaConstant), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(18),
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
/* 31 E> */ B(Throw),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 31 S> */ B(LdaNamedProperty), R(6), U8(4), U8(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 34 S> */ B(LdaNamedProperty), R(6), U8(5), U8(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(2),
[inspector] moved var initialization break location before init expression (reland) This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294 Reviewed-on: https://chromium-review.googlesource.com/518116 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45598}
2017-05-30 12:25:55 +00:00
/* 56 S> */ B(Ldar), R(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 58 E> */ B(Add), R(1), U8(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(0),
B(LdaZero),
B(Star), R(9),
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
B(JumpLoop), U8(91), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(36),
[Interpreter] Only materialize output register if in a different equivalence set. We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-02 19:03:03 +00:00
B(Star), R(17),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
/* 56 E> */ B(CreateCatchContext), R(17), U8(6), U8(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PushContext), R(17),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(9), U8(23),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfFalse), U8(6),
B(LdaSmi), I8(1),
B(Star), R(9),
B(LdaImmutableCurrentContextSlot), U8(4),
B(Star), R(18),
B(CallRuntime), U16(Runtime::kReThrow), R(18), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(9), U8(24),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(7), U8(8), U8(25),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(11),
B(TestUndetectable),
B(JumpIfFalse), U8(4),
B(Jump), U8(93),
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(9), U8(28),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(61),
B(Ldar), R(11),
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(16),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
B(LdaConstant), U8(9),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kNewTypeError), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(16),
B(Mov), R(11), R(17),
B(Mov), R(7), R(18),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(17), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(20),
B(Star), R(17),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
B(CreateCatchContext), R(17), U8(6), U8(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(16),
B(PushContext), R(17),
B(PopContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(11), R(16),
B(Mov), R(7), R(17),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Star), R(12),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(12), U8(1),
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(12), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(13),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 65 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["y"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
[parser] Better error message when destructuring against undefined/null Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
2017-06-15 21:24:37 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
FIXED_ARRAY_TYPE,
]
handlers: [
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
[7, 162, 168],
[10, 126, 128],
[228, 238, 240],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function* f(arr) {
for (let x of arr) { let y = x; }
}
f([1, 2, 3]);
"
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
frame size: 20
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
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
bytecode array length: 358
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
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(Mov), R(new_target), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(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),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(11), U8(1),
B(PushContext), R(13),
B(RestoreGeneratorState), R(11),
B(Star), R(12),
[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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kAbort), R(13), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(Star), R(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
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(PushContext), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(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
B(Mov), R(closure), R(14),
B(Mov), R(this), R(15),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(14), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(3),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 11 E> */ B(StackCheck),
B(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(3), R(11),
B(Mov), R(3), R(14),
/* 11 E> */ B(SuspendGenerator), R(11), R(0), U8(14), U8(0),
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 55 S> */ B(Return),
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(RestoreGeneratorRegisters), R(11), R(0), U8(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
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(Star), R(12),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(11), U8(1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(11), 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),
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(14),
[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),
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(14),
/* 55 S> */ B(Return),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(16),
B(Mov), R(context), R(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 35 S> */ B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(18),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(18), U8(3), U8(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
B(Star), R(19),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(19), R(18), 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(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(5),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 30 S> */ B(LdaNamedProperty), R(5), U8(4), U8(10),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(18), R(5), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
/* 30 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(6), U8(5), U8(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfToBooleanTrue), U8(28),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(6), U8(6), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaSmi), I8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(Mov), R(8), R(4),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 21 E> */ B(StackCheck),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(4), R(1),
/* 50 S> */ B(Mov), R(1), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(JumpLoop), U8(53), I8(0),
B(Jump), U8(36),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
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
/* 50 E> */ B(CreateCatchContext), R(18), U8(7), U8(8),
B(PushContext), R(18),
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(19),
B(CallRuntime), U16(Runtime::kReThrow), R(19), U8(1),
B(PopContext), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(Jump), U8(7),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(15),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(9), U8(18),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
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(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(61),
B(Ldar), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(LdaConstant), U8(10),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(17),
B(Mov), R(9), R(18),
B(Mov), R(5), R(19),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(18), 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(Jump), U8(20),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
[Interpreter] 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),
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(CreateCatchContext), R(18), U8(7), U8(11),
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
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(17),
B(PushContext), R(18),
B(PopContext), R(18),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(9), R(17),
B(Mov), R(5), R(18),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(17), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(10),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(10), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), U8(1),
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(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
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(TestEqualStrictNoFeedback), R(14),
B(JumpIfFalse), U8(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(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 55 S> */ B(Return),
]
constant pool: [
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
Smi [53],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
]
handlers: [
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
[104, 222, 228],
[107, 186, 188],
[288, 298, 300],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
function* f(arr) {
for (let x of arr) yield x;
}
f([1, 2, 3]);
"
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
frame size: 20
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
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
bytecode array length: 437
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
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(Mov), R(new_target), 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(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),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(10), U8(1),
B(PushContext), R(12),
B(RestoreGeneratorState), R(10),
B(Star), R(11),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(SwitchOnSmiNoFeedback), U8(0), U8(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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(12),
B(CallRuntime), U16(Runtime::kAbort), R(12), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(Star), R(11),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
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(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(closure), R(13),
B(Mov), R(this), R(14),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(13), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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),
B(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(2), R(10),
B(Mov), R(2), R(13),
/* 11 E> */ B(SuspendGenerator), R(10), R(0), U8(13), U8(0),
B(Ldar), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 49 S> */ B(Return),
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(RestoreGeneratorRegisters), R(10), R(0), U8(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
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(Star), R(11),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(10), U8(1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(10), 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),
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(13),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 11 E> */ B(Throw),
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(13),
/* 49 S> */ B(Return),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(15),
B(Mov), R(context), R(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 35 S> */ B(LdaImmutableCurrentContextSlot), U8(4),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(17), U8(4), U8(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
B(Star), R(18),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(18), R(17), 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(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(4),
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(Ldar), R(11),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(5), U8(1), I8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
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
/* 35 E> */ B(TestEqualStrictNoFeedback), R(11),
[ignition] Introduce Switch bytecode for generators Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 16:31:05 +00:00
B(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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kAbort), R(17), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 30 S> */ B(LdaNamedProperty), R(4), U8(6), U8(10),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(17), R(4), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(5),
/* 30 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(5), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(5), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(7), U8(12),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(JumpIfToBooleanTrue), U8(79),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(8), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaSmi), I8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
B(Mov), R(7), R(3),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 21 E> */ B(StackCheck),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(3), R(0),
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
/* 40 S> */ B(LdaSmi), I8(1),
B(Mov), R(0), R(17),
B(SuspendGenerator), R(10), R(0), U8(17), U8(0),
B(LdaFalse),
B(Star), R(19),
B(Mov), R(17), R(18),
B(InvokeIntrinsic), U8(Runtime::k_CreateIterResultObject), R(18), 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
/* 49 S> */ B(Return),
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(RestoreGeneratorRegisters), R(10), R(0), U8(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
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(Star), R(11),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(10), U8(1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(10), U8(1),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(9), U8(2), I8(0),
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(17),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
/* 40 E> */ B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
B(Mov), R(17), R(14),
[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(Jump), 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
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
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(JumpLoop), U8(125), I8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(36),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
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(CreateCatchContext), R(17), U8(11), U8(12),
B(PushContext), R(17),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(6), U8(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
B(CallRuntime), U16(Runtime::kReThrow), R(18), U8(1),
B(PopContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
B(Jump), U8(8),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
[Interpreter] 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(6), U8(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(4), U8(13), U8(18),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
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(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(6), U8(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(61),
B(Ldar), 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(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(16),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(LdaConstant), U8(14),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
B(CallRuntime), U16(Runtime::kNewTypeError), R(16), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(16),
B(Mov), R(8), R(17),
B(Mov), R(4), R(18),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(17), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(20),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
[Interpreter] 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),
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(CreateCatchContext), R(17), U8(11), U8(15),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
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(16),
B(PushContext), R(17),
B(PopContext), R(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(8), R(16),
B(Mov), R(4), R(17),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(16), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(9),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(9), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(9), U8(1),
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(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
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(13),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(SwitchOnSmiNoFeedback), U8(16), U8(2), I8(0),
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
B(Jump), U8(8),
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(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 49 S> */ B(Return),
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(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 49 S> */ B(Return),
]
constant pool: [
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
Smi [53],
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 [113],
Smi [10],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
SYMBOL_TYPE,
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
Smi [87],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
Smi [15],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
[ignition] Use jump table for "finally" deferred commands Bug: v8:6218 Change-Id: I5d245ea485c93fcc03fcd95c82ae0474f31ffa5e Reviewed-on: https://chromium-review.googlesource.com/505491 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45341}
2017-05-16 11:36:04 +00:00
Smi [6],
Move closing of generators upon final return to the generator-resume builtin. Review-Url: https://codereview.chromium.org/2936813002 Cr-Commit-Position: refs/heads/master@{#45906}
2017-06-13 13:49:45 +00:00
Smi [9],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
handlers: [
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
[104, 294, 300],
[107, 258, 260],
[361, 371, 373],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
async function f(arr) {
for (let x of arr) { let y = x; }
}
f([1, 2, 3]);
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 23
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
parameter count: 2
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
bytecode array length: 397
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
bytecodes: [
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
B(PushContext), R(12),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(4),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 16 E> */ B(StackCheck),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
B(CallJSRuntime), U8(%async_function_promise_create), R(13), 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
B(Star), R(11),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(15),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(context), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(19),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(context), R(20),
/* 40 S> */ B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(21),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(21), U8(0), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(22),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(22), R(21), 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(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(5),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 35 S> */ B(LdaNamedProperty), R(5), U8(1), U8(10),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(21),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(21), R(5), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(6),
/* 35 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(6), U8(2), U8(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfToBooleanTrue), U8(28),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(6), U8(3), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
B(LdaSmi), I8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(Mov), R(8), R(4),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 26 E> */ B(StackCheck),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Mov), R(4), R(1),
/* 55 S> */ B(Mov), R(1), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
B(JumpLoop), U8(53), I8(0),
B(Jump), U8(40),
B(Star), R(21),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
/* 55 E> */ B(CreateCatchContext), R(21), U8(4), U8(5),
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(20),
B(PushContext), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(22),
B(CallRuntime), U16(Runtime::kReThrow), R(22), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(7),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(18),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaZero),
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(6), U8(18),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
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(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(61),
B(Ldar), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(20),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(LdaConstant), U8(7),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(21),
B(CallRuntime), U16(Runtime::kNewTypeError), R(20), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(20),
B(Mov), R(9), R(21),
B(Mov), R(5), R(22),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(21), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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(20),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(21),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(21), U8(4), U8(8),
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(20),
B(PushContext), R(21),
B(PopContext), R(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(9), R(20),
B(Mov), R(5), R(21),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(20), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(10),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(10), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[ignition] Use jump for single deferred commands For a single deferred commands, using a jump table is overkill, so instead simply test the token against the single entry. Bug: v8:4280 Bug: v8:6218 Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77 Reviewed-on: https://chromium-review.googlesource.com/506153 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45393}
2017-05-16 16:38:52 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(TestEqualStrictNoFeedback), R(17),
[interpreter] Avoid redundant {PopContext} instructions. This avoids emitting redundant {PopContext} bytecode instructions when non-local control-flow leaves the method body. It also folds multiple such {PopContext} instructions into one, in case several scoping levels are crossed at one. Only the expected context of the target of a local control-flow transfer matters. R=rmcilroy@chromium.org TEST=debugger/regress/regress-crbug-724858 BUG=chromium:724858 Change-Id: Id4a47ae9fea25e75ae1af13619720b16a3975edf Reviewed-on: https://chromium-review.googlesource.com/512545 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45507}
2017-05-24 08:08:21 +00:00
B(JumpIfFalse), U8(5),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(19),
B(Mov), R(11), R(18),
B(CallJSRuntime), U8(%promise_resolve), R(17), 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),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
B(Mov), R(11), R(14),
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),
B(Star), R(17),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(closure),
B(CreateCatchContext), R(17), U8(4), U8(9),
B(Star), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(16),
B(PushContext), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(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(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaFalse),
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(21),
B(Mov), R(11), R(19),
B(CallJSRuntime), U8(%promise_internal_reject), R(18), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(PopContext), R(17),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(LdaZero),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
B(Mov), R(11), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(8),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(14),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(1),
B(Star), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(16),
B(Mov), R(11), R(17),
B(CallJSRuntime), U8(%async_function_promise_release), R(16), U8(2),
B(Ldar), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(13),
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(10), U8(2), I8(0),
[ignition] Re-use deferred return/rethrow commands Since deferred return/async return/rethrow commands don't have an associated statement, we can reuse their entries in the deferred command list. Bug: v8:4280 Bug: v8:6218 Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac Reviewed-on: https://chromium-review.googlesource.com/506077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45344}
2017-05-16 15:20:09 +00:00
B(Jump), U8(8),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 60 S> */ B(Return),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Ldar), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 60 S> */ B(Return),
]
constant pool: [
SYMBOL_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
FIXED_ARRAY_TYPE,
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: [
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
[21, 352, 358],
[24, 307, 309],
[30, 152, 158],
[33, 112, 114],
[218, 228, 230],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
]
---
snippet: "
async function f(arr) {
for (let x of arr) await x;
}
f([1, 2, 3]);
"
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
frame size: 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
parameter count: 2
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
bytecode array length: 537
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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: [
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(Mov), R(new_target), R(11),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(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),
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(InvokeIntrinsic), U8(Runtime::k_GeneratorGetContext), R(11), U8(1),
B(PushContext), R(13),
B(RestoreGeneratorState), R(11),
B(Star), R(12),
[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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kAbort), R(13), U8(1),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(LdaSmi), I8(-2),
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(Star), R(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(CreateFunctionContext), U8(1),
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(PushContext), R(13),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Ldar), R(arg0),
B(StaCurrentContextSlot), U8(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
B(Mov), R(closure), R(14),
B(Mov), R(this), R(15),
B(InvokeIntrinsic), U8(Runtime::k_CreateJSGeneratorObject), R(14), U8(2),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(2),
[ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject. Bug: v8:6351 Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65 Reviewed-on: https://chromium-review.googlesource.com/500507 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45281}
2017-05-12 17:29:53 +00:00
/* 16 E> */ B(StackCheck),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
B(CallJSRuntime), U8(%async_function_promise_create), R(14), U8(1),
[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(3),
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(Mov), R(2), R(11),
[ignition] Fix register flushing performance issue In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
2017-06-09 09:26:27 +00:00
B(Mov), R(context), R(16),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(Star), R(7),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(20),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Mov), R(context), R(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
/* 40 S> */ B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(22),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(22), U8(1), U8(4),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(Star), R(23),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(23), R(22), 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(JumpIfJSReceiver), U8(7),
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
[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),
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(Ldar), R(12),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(SwitchOnSmiNoFeedback), U8(2), U8(1), I8(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
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
/* 40 E> */ B(TestEqualStrictNoFeedback), R(12),
[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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
B(CallRuntime), U16(Runtime::kAbort), R(22), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 35 S> */ B(LdaNamedProperty), R(5), U8(3), U8(10),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(CallProperty0), R(22), R(5), U8(8),
[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(6),
/* 35 E> */ B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(6), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ToBooleanLogicalNot),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(7),
[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(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(6), U8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(6), U8(4), U8(12),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(JumpIfToBooleanTrue), U8(86),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(6), U8(5), U8(14),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Star), R(8),
[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(LdaSmi), I8(2),
B(Star), R(7),
B(Mov), R(8), R(4),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 26 E> */ B(StackCheck),
[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(Mov), R(4), R(0),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 45 S> */ B(LdaUndefined),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
B(Mov), R(2), R(23),
B(Mov), R(4), R(24),
B(Mov), R(3), R(25),
/* 51 E> */ B(CallJSRuntime), U8(%async_function_await_uncaught), R(22), U8(4),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(3), R(22),
B(SuspendGenerator), R(11), R(0), U8(22), U8(2),
B(Ldar), R(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
/* 54 S> */ B(Return),
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(RestoreGeneratorRegisters), R(11), R(0), U8(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-2),
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(Star), R(12),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetInputOrDebugPos), R(11), U8(1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(11), 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(6), U8(2), I8(0),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Ldar), R(22),
[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
/* 45 E> */ B(ReThrow),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
B(Mov), R(22), R(19),
[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(Jump), U8(60),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(Star), R(7),
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(JumpLoop), U8(132), I8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(40),
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(Star), R(22),
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),
B(CreateCatchContext), R(22), U8(8), U8(9),
B(Star), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
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(21),
B(PushContext), R(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(2),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(16),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(6),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
[inspector] removed break location right before suspension in async function In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
2017-05-31 11:40:31 +00:00
B(Star), R(7),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(23),
B(CallRuntime), U16(Runtime::kReThrow), R(23), U8(1),
B(PopContext), R(22),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(-1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
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),
B(Star), R(19),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(LdaSmi), I8(1),
B(Star), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaZero),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(17),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfTrue), U8(104),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(LdaNamedProperty), R(5), U8(10), U8(18),
[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(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestUndetectable),
B(JumpIfFalse), U8(4),
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(93),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaSmi), I8(1),
[runtime] Move profiler ticks from SFI to feedback vector 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: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(TestEqualStrict), R(7), U8(21),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(JumpIfFalse), U8(61),
[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(Ldar), R(9),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(TestTypeOf), U8(5),
B(JumpIfFalse), U8(4),
B(Jump), U8(18),
[runtime] Create only one instance of %ThrowTypeError%. ... according to the spec ES#sec-%throwtypeerror% Bug: v8:4034 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a Reviewed-on: https://chromium-review.googlesource.com/563214 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46498}
2017-07-10 07:57:09 +00:00
B(Wide), B(LdaSmi), I16(131),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(21),
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
B(LdaConstant), U8(11),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
B(CallRuntime), U16(Runtime::kNewTypeError), R(21), U8(2),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Throw),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(context), R(21),
B(Mov), R(9), R(22),
B(Mov), R(5), R(23),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(22), 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(Jump), U8(20),
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(Star), R(22),
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),
B(CreateCatchContext), R(22), U8(8), U8(12),
B(Star), R(21),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
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(21),
B(PushContext), R(22),
B(PopContext), R(22),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(27),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Mov), R(9), R(21),
B(Mov), R(5), R(22),
B(InvokeIntrinsic), U8(Runtime::k_Call), R(21), U8(2),
[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(10),
B(InvokeIntrinsic), U8(Runtime::k_IsJSReceiver), R(10), U8(1),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(JumpIfToBooleanFalse), U8(4),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(7),
[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(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(10), U8(1),
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(20),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
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(18),
[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(13), U8(2), I8(0),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(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(LdaZero),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
B(Mov), R(19), R(15),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(83),
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(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(20),
B(Mov), R(3), R(19),
B(CallJSRuntime), U8(%promise_resolve), R(18), 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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
B(Mov), R(3), R(15),
Make non-Module generators only context allocate parameters. In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
2017-05-24 13:54:57 +00:00
B(Jump), U8(59),
B(Jump), U8(45),
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(Star), R(18),
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),
B(CreateCatchContext), R(18), U8(8), U8(15),
B(Star), R(17),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
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(17),
B(PushContext), R(18),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaUndefined),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(19),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaImmutableCurrentContextSlot), U8(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
B(Star), R(21),
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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(22),
B(Mov), R(3), R(20),
B(CallJSRuntime), U8(%promise_internal_reject), R(19), U8(4),
B(PopContext), R(18),
[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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
B(Mov), R(3), R(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(Jump), U8(14),
B(LdaSmi), I8(-1),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(14),
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),
B(Star), R(15),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(LdaSmi), I8(1),
B(Star), R(14),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(LdaTheHole),
B(SetPendingMessage),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(16),
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),
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
B(Star), R(17),
B(Mov), R(3), R(18),
B(CallJSRuntime), U8(%async_function_promise_release), R(17), U8(2),
B(Ldar), R(16),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(SetPendingMessage),
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(14),
[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(16), 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),
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(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
/* 54 S> */ B(Return),
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(15),
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
B(ReThrow),
B(LdaUndefined),
/* 54 S> */ B(Return),
]
constant pool: [
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
Smi [88],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
SYMBOL_TYPE,
[generators] Remove generator_object_ member from Suspend AST node Now that the BytecodeGenerator has a dedicated register holding the generator object, BytecodeGenerator::VisitSuspend can access the generator directly from that register. This reduces by one the number of live registers at each suspend point. Bug: v8:6351, v8:6460 Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d Reviewed-on: https://chromium-review.googlesource.com/522982 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45710}
2017-06-05 17:41:26 +00:00
Smi [94],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
Move generator-close on exception from the generator function to the GeneratorResume builtin. The change also moves creation of the iterator result from the parser to the bytecode generator. Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work. Review-Url: https://codereview.chromium.org/2917263002 Cr-Commit-Position: refs/heads/master@{#45713}
2017-06-05 19:54:14 +00:00
Smi [15],
[ignition] Use jump table for generator resume mode Bug: v8:6351 Change-Id: Iad82fcfb4172d7a9cbadffa1e40fd1cd26866895 Reviewed-on: https://chromium-review.googlesource.com/521107 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45705}
2017-06-05 13:23:20 +00:00
Smi [7],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44731}
2017-04-18 14:56:06 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE [".catch"],
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
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],
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
Smi [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
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: [
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
[70, 492, 498],
[73, 447, 449],
[79, 280, 286],
[82, 240, 242],
[347, 357, 359],
[parser] avoid complex for-loop desugaring when possible let/const declarations in "standard" C-style for-loops have some complex desugaring to accommodate the case where loop loop variables may be captured. This slows down the baseline performance of for-loops with let variables. This change attempts to avoid this desugaring if it's known that the loop variable is not captured at any point. A side effect of this change is that let/const loop variables, when not captured within the loop body, are not necessarily shown in the debugger, similar to other stack-allocated vars. BUG=v8:4762, v8:5460 R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org Change-Id: I8dbe545a12c086f675972bdba60c94998268311a Reviewed-on: https://chromium-review.googlesource.com/472247 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.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