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

241 lines
7.1 KiB
Plaintext
Raw Normal View History

[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: yes
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
test function name: f
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
---
snippet: "
eval('var x = 10;'); return x;
"
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
frame size: 9
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 1
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
bytecode array length: 62
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add CreateFunctionContext bytecode Add a new bytecode to create a function context. The handler inlines FastNewFunctionContextStub. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2187523002 Cr-Commit-Position: refs/heads/master@{#38301}
2016-08-03 14:41:47 +00:00
B(CreateFunctionContext), U8(3),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(PushContext), R(0),
B(Ldar), R(this),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(CreateMappedArguments),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(6),
Reland - Allow lexically declared "arguments" in function scope in sloppy mode. Lexically declared "arguments" in sloppy mode will throw redeclaration error currently, this patch fixes it by delaying the declaration of arguments until we fully parse parameter list and function body. BUG=v8:4577 LOG=N Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa Review-Url: https://codereview.chromium.org/2290753003 Cr-Original-Commit-Position: refs/heads/master@{#39109} Cr-Commit-Position: refs/heads/master@{#39230}
2016-09-07 06:54:36 +00:00
B(Ldar), R(new_target),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(5),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
/* 10 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 14 S> */ B(LdaLookupGlobalSlot), U8(0), U8(6), U8(1),
Only treat possible eval calls going through 'with' as special. This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime call to find the callee and possibly update the receiver with the with-object. This means that eval calls out of 'with' blocks can now just do a normal LdaLookupGlobalSlot operation, which can check the context chain for eval extentions and fast-path the lookup if none exist. BUG=661556 Review-Url: https://codereview.chromium.org/2487483004 Cr-Commit-Position: refs/heads/master@{#40965}
2016-11-14 13:34:26 +00:00
B(Star), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaConstant), U8(1),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(6),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(10),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(7),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(14),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(8),
B(Mov), R(1), R(3),
B(Mov), R(2), R(4),
B(Mov), R(closure), R(5),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(3), U8(6),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 14 E> */ B(CallUndefinedReceiver1), R(1), R(2), U8(4),
/* 35 S> */ B(LdaLookupGlobalSlot), U8(2), U8(8), U8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 44 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["var x = 10;"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
---
snippet: "
eval('var x = 10;'); return typeof x;
"
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
frame size: 9
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 1
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
bytecode array length: 63
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add CreateFunctionContext bytecode Add a new bytecode to create a function context. The handler inlines FastNewFunctionContextStub. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2187523002 Cr-Commit-Position: refs/heads/master@{#38301}
2016-08-03 14:41:47 +00:00
B(CreateFunctionContext), U8(3),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(PushContext), R(0),
B(Ldar), R(this),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(CreateMappedArguments),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(6),
Reland - Allow lexically declared "arguments" in function scope in sloppy mode. Lexically declared "arguments" in sloppy mode will throw redeclaration error currently, this patch fixes it by delaying the declaration of arguments until we fully parse parameter list and function body. BUG=v8:4577 LOG=N Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa Review-Url: https://codereview.chromium.org/2290753003 Cr-Original-Commit-Position: refs/heads/master@{#39109} Cr-Commit-Position: refs/heads/master@{#39230}
2016-09-07 06:54:36 +00:00
B(Ldar), R(new_target),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(5),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
/* 10 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 14 S> */ B(LdaLookupGlobalSlot), U8(0), U8(6), U8(1),
Only treat possible eval calls going through 'with' as special. This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime call to find the callee and possibly update the receiver with the with-object. This means that eval calls out of 'with' blocks can now just do a normal LdaLookupGlobalSlot operation, which can check the context chain for eval extentions and fast-path the lookup if none exist. BUG=661556 Review-Url: https://codereview.chromium.org/2487483004 Cr-Commit-Position: refs/heads/master@{#40965}
2016-11-14 13:34:26 +00:00
B(Star), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaConstant), U8(1),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(6),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(10),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(7),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(14),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(8),
B(Mov), R(1), R(3),
B(Mov), R(2), R(4),
B(Mov), R(closure), R(5),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(3), U8(6),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 14 E> */ B(CallUndefinedReceiver1), R(1), R(2), U8(4),
/* 35 S> */ B(LdaLookupGlobalSlotInsideTypeof), U8(2), U8(8), U8(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(TypeOf),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 51 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["var x = 10;"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
---
snippet: "
x = 20; return eval('');
"
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
frame size: 9
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 1
[scopes] Fix sloppy-mode block-scoped function hoisting edge case In edge cases such as the following, sloppy-mode block-scoped function hoisting is expected to occur: eval(` with({a: 1}) { function a() {} } `) In this case, there should be the equivalent of a var declaration outside of the eval, which gets set to the value of the local function a when the body of the with is executed. Previously, the way that var declarations are hoisted out of eval meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL assignment. However, such a lookup mode meant that the object in the with scope received the assignment! This patch fixes that error by marking the assignments produced by the sloppy mode block scoped function hoisting desugaring so as to generate a different runtime call which skips with scopes. Bug: chromium:720247, v8:5135 Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748 Reviewed-on: https://chromium-review.googlesource.com/529230 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46116}
2017-06-22 07:49:08 +00:00
bytecode array length: 63
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add CreateFunctionContext bytecode Add a new bytecode to create a function context. The handler inlines FastNewFunctionContextStub. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2187523002 Cr-Commit-Position: refs/heads/master@{#38301}
2016-08-03 14:41:47 +00:00
B(CreateFunctionContext), U8(3),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(PushContext), R(0),
B(Ldar), R(this),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(CreateMappedArguments),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(6),
Reland - Allow lexically declared "arguments" in function scope in sloppy mode. Lexically declared "arguments" in sloppy mode will throw redeclaration error currently, this patch fixes it by delaying the declaration of arguments until we fully parse parameter list and function body. BUG=v8:4577 LOG=N Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa Review-Url: https://codereview.chromium.org/2290753003 Cr-Original-Commit-Position: refs/heads/master@{#39109} Cr-Commit-Position: refs/heads/master@{#39230}
2016-09-07 06:54:36 +00:00
B(Ldar), R(new_target),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(5),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
/* 10 E> */ B(StackCheck),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 14 S> */ B(LdaSmi), I8(20),
[scopes] Fix sloppy-mode block-scoped function hoisting edge case In edge cases such as the following, sloppy-mode block-scoped function hoisting is expected to occur: eval(` with({a: 1}) { function a() {} } `) In this case, there should be the equivalent of a var declaration outside of the eval, which gets set to the value of the local function a when the body of the with is executed. Previously, the way that var declarations are hoisted out of eval meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL assignment. However, such a lookup mode meant that the object in the with scope received the assignment! This patch fixes that error by marking the assignments produced by the sloppy mode block scoped function hoisting desugaring so as to generate a different runtime call which skips with scopes. Bug: chromium:720247, v8:5135 Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748 Reviewed-on: https://chromium-review.googlesource.com/529230 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46116}
2017-06-22 07:49:08 +00:00
/* 16 E> */ B(StaLookupSlot), U8(0), U8(0),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 22 S> */ B(LdaLookupGlobalSlot), U8(1), U8(6), U8(1),
Only treat possible eval calls going through 'with' as special. This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime call to find the callee and possibly update the receiver with the with-object. This means that eval calls out of 'with' blocks can now just do a normal LdaLookupGlobalSlot operation, which can check the context chain for eval extentions and fast-path the lookup if none exist. BUG=661556 Review-Url: https://codereview.chromium.org/2487483004 Cr-Commit-Position: refs/heads/master@{#40965}
2016-11-14 13:34:26 +00:00
B(Star), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaConstant), U8(2),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(6),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(10),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(7),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(29),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(8),
B(Mov), R(1), R(3),
B(Mov), R(2), R(4),
B(Mov), R(closure), R(5),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(3), U8(6),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 29 E> */ B(CallUndefinedReceiver1), R(1), R(2), U8(4),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 38 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE [""],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
---
snippet: "
var x = 20;
f = function(){
eval('var x = 10');
return x;
}
f();
"
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
frame size: 9
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
parameter count: 1
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
bytecode array length: 62
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
bytecodes: [
B(CreateFunctionContext), U8(3),
B(PushContext), R(0),
B(Ldar), R(this),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
B(CreateMappedArguments),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(6),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
B(Ldar), R(new_target),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(5),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
/* 38 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 44 S> */ B(LdaLookupGlobalSlot), U8(0), U8(6), U8(1),
Only treat possible eval calls going through 'with' as special. This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime call to find the callee and possibly update the receiver with the with-object. This means that eval calls out of 'with' blocks can now just do a normal LdaLookupGlobalSlot operation, which can check the context chain for eval extentions and fast-path the lookup if none exist. BUG=661556 Review-Url: https://codereview.chromium.org/2487483004 Cr-Commit-Position: refs/heads/master@{#40965}
2016-11-14 13:34:26 +00:00
B(Star), R(1),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
B(LdaConstant), U8(1),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(2),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
B(LdaZero),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(6),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(38),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(7),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(44),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(8),
B(Mov), R(1), R(3),
B(Mov), R(2), R(4),
B(Mov), R(closure), R(5),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(3), U8(6),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 44 E> */ B(CallUndefinedReceiver1), R(1), R(2), U8(4),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
/* 66 S> */ B(LdaLookupContextSlot), U8(2), U8(6), U8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 75 S> */ B(Return),
[interpreter] Add a fast path for dynamic local load Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup variables that can be context loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2343633002 Cr-Commit-Position: refs/heads/master@{#39473}
2016-09-16 13:26:44 +00:00
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["var x = 10"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
]
handlers: [
]
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
---
snippet: "
x = 20;
f = function(){
eval('var x = 10');
return x;
}
f();
"
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
frame size: 9
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
parameter count: 1
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
bytecode array length: 62
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
bytecodes: [
B(CreateFunctionContext), U8(3),
B(PushContext), R(0),
B(Ldar), R(this),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(4),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
B(CreateMappedArguments),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(6),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
B(Ldar), R(new_target),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
B(StaCurrentContextSlot), U8(5),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
/* 34 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 40 S> */ B(LdaLookupGlobalSlot), U8(0), U8(6), U8(1),
Only treat possible eval calls going through 'with' as special. This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime call to find the callee and possibly update the receiver with the with-object. This means that eval calls out of 'with' blocks can now just do a normal LdaLookupGlobalSlot operation, which can check the context chain for eval extentions and fast-path the lookup if none exist. BUG=661556 Review-Url: https://codereview.chromium.org/2487483004 Cr-Commit-Position: refs/heads/master@{#40965}
2016-11-14 13:34:26 +00:00
B(Star), R(1),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
B(LdaConstant), U8(1),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(2),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
B(LdaZero),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(6),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(34),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(7),
Revert "[ignition] Add call bytecodes for undefined receiver" This reverts commit 751e89359123df4f6e5f0b28b89fcdf63ed16a77. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
2017-04-11 06:26:10 +00:00
B(LdaSmi), I8(40),
Reland: [ignition] Add call bytecodes for undefined receiver Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
2017-04-11 14:20:30 +00:00
B(Star), R(8),
B(Mov), R(1), R(3),
B(Mov), R(2), R(4),
B(Mov), R(closure), R(5),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(3), U8(6),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
B(Star), R(1),
[runtime] Move profiler ticks from SFI to feedback vector (reland) Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:24:21 +00:00
/* 40 E> */ B(CallUndefinedReceiver1), R(1), R(2), U8(4),
/* 62 S> */ B(LdaLookupGlobalSlot), U8(2), U8(8), U8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 71 S> */ B(Return),
[interpreter] Add fast path for dynamic global lookups Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup variables that can be globally loaded, without calling the runtime, as long as there was no context extension by a sloppy eval along their context chain. BUG=v8:5263 Review-Url: https://codereview.chromium.org/2347143002 Cr-Commit-Position: refs/heads/master@{#39537}
2016-09-20 10:31:24 +00:00
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["eval"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["var x = 10"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
]
handlers: [
]
Reference in New Issue Copy Permalink