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

251 lines
7.4 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;
"
Correctly annotate eval origin. There were a couple of issues with it: - interpreter is not supported - the source position was just accidentally correct for full-codegen - the eval origin could have been cached Also fixes a few other places to use AbstractCode. R=mstarzinger@chromium.org Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d Cr-Commit-Position: refs/heads/master@{#35257} Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16 Cr-Commit-Position: refs/heads/master@{#35481} Review URL: https://codereview.chromium.org/1854713002 Cr-Commit-Position: refs/heads/master@{#35581}
2016-04-18 13:20:45 +00:00
frame size: 10
[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
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
bytecode array length: 66
[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),
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
/* 14 S> */ B(LdaUndefined),
B(Star), R(2),
/* 14 E> */ B(LdaLookupGlobalSlot), U8(0), U8(4), U8(1),
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),
B(Star), R(3),
B(LdaZero),
B(Star), R(7),
[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(LdaSmi), U8(10),
[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(8),
[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(LdaSmi), U8(14),
[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(9),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
B(Mov), R(1), R(4),
B(Mov), R(3), R(5),
B(Mov), R(closure), R(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(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(4), U8(6),
B(Star), R(1),
[ic] Unify CallIC feedback collection and handling. Consistently collect CallIC feedback in fullcodegen and Ignition, even for possibly direct eval calls, that were treated specially so far, for no apparent reason. With the upcoming SharedFunctionInfo based CallIC feedback, we might be able to even inline certain direct eval calls, if they manage to hit the eval cache. More importantly, this patch simplifies the collection and dealing with CallIC feedback (and as a side effect fixes an inconsistency with feedback for super constructor calls). R=mvstanton@chromium.org, mythria@chromium.org BUG=v8:2206,v8:4280,v8:5267 Review-Url: https://codereview.chromium.org/2426693002 Cr-Commit-Position: refs/heads/master@{#40397}
2016-10-18 12:01:05 +00:00
/* 14 E> */ B(Call), R(1), R(2), U8(2), U8(2),
/* 35 S> */ B(LdaLookupGlobalSlot), U8(2), U8(6), U8(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
/* 45 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;
"
Correctly annotate eval origin. There were a couple of issues with it: - interpreter is not supported - the source position was just accidentally correct for full-codegen - the eval origin could have been cached Also fixes a few other places to use AbstractCode. R=mstarzinger@chromium.org Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d Cr-Commit-Position: refs/heads/master@{#35257} Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16 Cr-Commit-Position: refs/heads/master@{#35481} Review URL: https://codereview.chromium.org/1854713002 Cr-Commit-Position: refs/heads/master@{#35581}
2016-04-18 13:20:45 +00:00
frame size: 10
[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
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
bytecode array length: 67
[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),
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
/* 14 S> */ B(LdaUndefined),
B(Star), R(2),
/* 14 E> */ B(LdaLookupGlobalSlot), U8(0), U8(4), U8(1),
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),
B(Star), R(3),
B(LdaZero),
B(Star), R(7),
[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(LdaSmi), U8(10),
[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(8),
[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(LdaSmi), U8(14),
[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(9),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
B(Mov), R(1), R(4),
B(Mov), R(3), R(5),
B(Mov), R(closure), R(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(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(4), U8(6),
B(Star), R(1),
[ic] Unify CallIC feedback collection and handling. Consistently collect CallIC feedback in fullcodegen and Ignition, even for possibly direct eval calls, that were treated specially so far, for no apparent reason. With the upcoming SharedFunctionInfo based CallIC feedback, we might be able to even inline certain direct eval calls, if they manage to hit the eval cache. More importantly, this patch simplifies the collection and dealing with CallIC feedback (and as a side effect fixes an inconsistency with feedback for super constructor calls). R=mvstanton@chromium.org, mythria@chromium.org BUG=v8:2206,v8:4280,v8:5267 Review-Url: https://codereview.chromium.org/2426693002 Cr-Commit-Position: refs/heads/master@{#40397}
2016-10-18 12:01:05 +00:00
/* 14 E> */ B(Call), R(1), R(2), U8(2), U8(2),
/* 35 S> */ B(LdaLookupGlobalSlotInsideTypeof), U8(2), U8(6), 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),
[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
/* 52 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('');
"
Correctly annotate eval origin. There were a couple of issues with it: - interpreter is not supported - the source position was just accidentally correct for full-codegen - the eval origin could have been cached Also fixes a few other places to use AbstractCode. R=mstarzinger@chromium.org Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d Cr-Commit-Position: refs/heads/master@{#35257} Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16 Cr-Commit-Position: refs/heads/master@{#35481} Review URL: https://codereview.chromium.org/1854713002 Cr-Commit-Position: refs/heads/master@{#35581}
2016-04-18 13:20:45 +00:00
frame size: 10
[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
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
bytecode array length: 66
[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),
/* 14 S> */ B(LdaSmi), U8(20),
/* 16 E> */ B(StaLookupSlotSloppy), U8(0),
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
/* 22 S> */ B(LdaUndefined),
B(Star), R(2),
/* 29 E> */ B(LdaLookupGlobalSlot), U8(1), U8(4), U8(1),
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),
B(Star), R(3),
B(LdaZero),
B(Star), R(7),
[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(LdaSmi), U8(10),
[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(8),
[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(LdaSmi), U8(29),
[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(9),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
B(Mov), R(1), R(4),
B(Mov), R(3), R(5),
B(Mov), R(closure), R(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(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(4), U8(6),
B(Star), R(1),
[ic] Unify CallIC feedback collection and handling. Consistently collect CallIC feedback in fullcodegen and Ignition, even for possibly direct eval calls, that were treated specially so far, for no apparent reason. With the upcoming SharedFunctionInfo based CallIC feedback, we might be able to even inline certain direct eval calls, if they manage to hit the eval cache. More importantly, this patch simplifies the collection and dealing with CallIC feedback (and as a side effect fixes an inconsistency with feedback for super constructor calls). R=mvstanton@chromium.org, mythria@chromium.org BUG=v8:2206,v8:4280,v8:5267 Review-Url: https://codereview.chromium.org/2426693002 Cr-Commit-Position: refs/heads/master@{#40397}
2016-10-18 12:01:05 +00:00
/* 29 E> */ B(Call), R(1), R(2), U8(2), U8(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
/* 39 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();
"
frame size: 10
parameter count: 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
bytecode array length: 66
[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),
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
/* 44 S> */ B(LdaUndefined),
B(Star), R(2),
/* 44 E> */ B(LdaLookupGlobalSlot), U8(0), U8(4), U8(1),
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),
B(Star), R(3),
B(LdaZero),
B(Star), R(7),
B(LdaSmi), U8(38),
B(Star), R(8),
B(LdaSmi), U8(44),
B(Star), R(9),
B(Mov), R(1), R(4),
B(Mov), R(3), R(5),
B(Mov), R(closure), R(6),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(4), U8(6),
B(Star), R(1),
[ic] Unify CallIC feedback collection and handling. Consistently collect CallIC feedback in fullcodegen and Ignition, even for possibly direct eval calls, that were treated specially so far, for no apparent reason. With the upcoming SharedFunctionInfo based CallIC feedback, we might be able to even inline certain direct eval calls, if they manage to hit the eval cache. More importantly, this patch simplifies the collection and dealing with CallIC feedback (and as a side effect fixes an inconsistency with feedback for super constructor calls). R=mvstanton@chromium.org, mythria@chromium.org BUG=v8:2206,v8:4280,v8:5267 Review-Url: https://codereview.chromium.org/2426693002 Cr-Commit-Position: refs/heads/master@{#40397}
2016-10-18 12:01:05 +00:00
/* 44 E> */ B(Call), R(1), R(2), U8(2), U8(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
/* 66 S> */ B(LdaLookupContextSlot), U8(2), U8(6), U8(1),
/* 76 S> */ B(Return),
]
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();
"
frame size: 10
parameter count: 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
bytecode array length: 66
[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),
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
/* 40 S> */ B(LdaUndefined),
B(Star), R(2),
/* 40 E> */ B(LdaLookupGlobalSlot), U8(0), U8(4), U8(1),
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),
B(Star), R(3),
B(LdaZero),
B(Star), R(7),
B(LdaSmi), U8(34),
B(Star), R(8),
B(LdaSmi), U8(40),
B(Star), R(9),
B(Mov), R(1), R(4),
B(Mov), R(3), R(5),
B(Mov), R(closure), R(6),
B(CallRuntime), U16(Runtime::kResolvePossiblyDirectEval), R(4), U8(6),
B(Star), R(1),
[ic] Unify CallIC feedback collection and handling. Consistently collect CallIC feedback in fullcodegen and Ignition, even for possibly direct eval calls, that were treated specially so far, for no apparent reason. With the upcoming SharedFunctionInfo based CallIC feedback, we might be able to even inline certain direct eval calls, if they manage to hit the eval cache. More importantly, this patch simplifies the collection and dealing with CallIC feedback (and as a side effect fixes an inconsistency with feedback for super constructor calls). R=mvstanton@chromium.org, mythria@chromium.org BUG=v8:2206,v8:4280,v8:5267 Review-Url: https://codereview.chromium.org/2426693002 Cr-Commit-Position: refs/heads/master@{#40397}
2016-10-18 12:01:05 +00:00
/* 40 E> */ B(Call), R(1), R(2), U8(2), U8(2),
/* 62 S> */ B(LdaLookupGlobalSlot), U8(2), U8(6), U8(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
/* 72 S> */ B(Return),
]
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