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

289 lines
8.8 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
---
snippet: "
class Person {
constructor(name) { this.name = name; }
speak() { console.log(this.name + ' is speaking.'); }
}
"
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +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
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
bytecode array length: 75
[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 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(LdaTheHole),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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
/* 30 E> */ B(StackCheck),
B(LdaTheHole),
B(Star), R(0),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
/* 34 S> */ B(CreateClosure), U8(0), U8(2), U8(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(Star), R(3),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[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(4),
[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
B(LdaSmi), I8(34),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Star), R(6),
[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
B(Wide), B(LdaSmi), I16(148),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(Star), R(7),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
B(Star), R(4),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaConstant), U8(1),
[ignition] Avoid unnecessary ToName calls in VisitClassLiteralProperties R=rmcilroy@chromium.org BUG=v8:5799 Review-Url: https://codereview.chromium.org/2612903002 Cr-Commit-Position: refs/heads/master@{#42098}
2017-01-05 18:25:25 +00:00
B(Star), R(6),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(CreateClosure), U8(2), U8(3), U8(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(Star), R(7),
[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
B(LdaSmi), I8(2),
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +00:00
B(Star), R(8),
B(Ldar), R(7),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(StaDataPropertyInLiteral), R(4), R(6), U8(1), U8(4),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(3), U8(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(CallRuntime), U16(Runtime::kToFastProperties), R(3), 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(Star), R(0),
[interpreter] Filter expression positions at source. With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:32:33 +00:00
B(Star), R(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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(LdaUndefined),
/* 149 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
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["speak"],
SHARED_FUNCTION_INFO_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: [
]
---
snippet: "
class person {
constructor(name) { this.name = name; }
speak() { console.log(this.name + ' is speaking.'); }
}
"
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +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
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
bytecode array length: 75
[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 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(LdaTheHole),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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
/* 30 E> */ B(StackCheck),
B(LdaTheHole),
B(Star), R(0),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
/* 34 S> */ B(CreateClosure), U8(0), U8(2), U8(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(Star), R(3),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[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(4),
[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
B(LdaSmi), I8(34),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Star), R(6),
[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
B(Wide), B(LdaSmi), I16(148),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(Star), R(7),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
B(Star), R(4),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaConstant), U8(1),
[ignition] Avoid unnecessary ToName calls in VisitClassLiteralProperties R=rmcilroy@chromium.org BUG=v8:5799 Review-Url: https://codereview.chromium.org/2612903002 Cr-Commit-Position: refs/heads/master@{#42098}
2017-01-05 18:25:25 +00:00
B(Star), R(6),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(CreateClosure), U8(2), U8(3), U8(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(Star), R(7),
[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
B(LdaSmi), I8(2),
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +00:00
B(Star), R(8),
B(Ldar), R(7),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(StaDataPropertyInLiteral), R(4), R(6), U8(1), U8(4),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(3), U8(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(CallRuntime), U16(Runtime::kToFastProperties), R(3), 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(Star), R(0),
[interpreter] Filter expression positions at source. With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:32:33 +00:00
B(Star), R(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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(LdaUndefined),
/* 149 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
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["speak"],
SHARED_FUNCTION_INFO_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: [
]
---
snippet: "
var n0 = 'a';
var n1 = 'b';
class N {
[n0]() { return n0; }
static [n1]() { return n1; }
}
"
[interpreter] Bytecode for StaDataPropertyInLiteral. Add bytecode for defining data properties, which initially just calls the runtime function. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2510743002 Cr-Commit-Position: refs/heads/master@{#41101}
2016-11-18 12:13:30 +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
[Interpreter] Introduce strict equality bytecode that does not collect feedback. Some of the StrictEquality comparisons do not require feedback (for ex: in try-finally, generators). This cl introduces StrictEqualityNoFeedback bytecode to be used in such cases. With this change, we no longer have to check if the type feedback slot is valid in compare bytecode handlers. This is the first step in reworking the compare bytecode handler to avoid duplicate checks when collecting feedback and when performing the operation. BUG=v8:4280 Change-Id: Ia650fd43c0466b8625d3ce98c39ed1073ba42a6b Reviewed-on: https://chromium-review.googlesource.com/455778 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#44020}
2017-03-22 11:08:18 +00:00
bytecode array length: 116
[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(2),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(PushContext), R(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(LdaTheHole),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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
/* 30 E> */ B(StackCheck),
/* 43 S> */ B(LdaConstant), U8(0),
[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
/* 43 E> */ 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
/* 57 S> */ B(LdaConstant), U8(1),
[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
/* 57 E> */ B(StaCurrentContextSlot), U8(5),
[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(LdaTheHole),
B(Star), R(0),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
/* 62 S> */ B(CreateClosure), U8(2), U8(2), U8(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(Star), R(4),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[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(5),
[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
B(LdaSmi), I8(62),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Star), R(7),
[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
B(Wide), B(LdaSmi), I16(128),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(Star), R(8),
B(Mov), R(4), R(6),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(4),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
B(Star), R(5),
Reland of Thread maybe-assigned through the bytecodes. (patchset #1 id:1 of https://codereview.chromium.org/2680923003/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ ) > > Reason for revert: > needed for properly reverting https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 > > Original issue's description: > > Thread maybe-assigned through the bytecodes. > > > > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot > > bytecodes, which are emitted when reading from never-assigned context slot. > > > > There is a subtlety here: the slot are not immutable, the meaning is > > actually undefined-or-hole-or-immutable. > > > > Review-Url: https://codereview.chromium.org/2655733003 > > Cr-Commit-Position: refs/heads/master@{#43000} > > Committed: https://chromium.googlesource.com/v8/v8/+/17c2dd388697da626224c371c8181d20d2016d82 > > TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Review-Url: https://codereview.chromium.org/2680923003 > Cr-Commit-Position: refs/heads/master@{#43011} > Committed: https://chromium.googlesource.com/v8/v8/+/ece4e54a31ac76ee9c450270d65270562db716e1 TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2679953003 Cr-Commit-Position: refs/heads/master@{#43012}
2017-02-07 20:42:03 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[Interpreter] Remove all Ldr style bytecodes and replace with Star lookahead. We seem to get some small wins from avoiding the Ldr bytecodes, probably due to reduced icache pressure since there are less bytecode handlers. Replace the Ldr bytecodes with Star lookahead inlined into the Lda versions. Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and LdaCurrentContextSlot BUG=v8:4280 Review-Url: https://codereview.chromium.org/2489513005 Cr-Commit-Position: refs/heads/master@{#40883}
2016-11-10 10:41:48 +00:00
/* 75 E> */ B(ToName), R(7),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(CreateClosure), U8(3), U8(3), U8(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(Star), R(8),
[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
B(LdaSmi), I8(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(Star), R(9),
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +00:00
B(Ldar), R(8),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(StaDataPropertyInLiteral), R(5), R(7), U8(3), U8(5),
Reland of Thread maybe-assigned through the bytecodes. (patchset #1 id:1 of https://codereview.chromium.org/2680923003/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ ) > > Reason for revert: > needed for properly reverting https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 > > Original issue's description: > > Thread maybe-assigned through the bytecodes. > > > > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot > > bytecodes, which are emitted when reading from never-assigned context slot. > > > > There is a subtlety here: the slot are not immutable, the meaning is > > actually undefined-or-hole-or-immutable. > > > > Review-Url: https://codereview.chromium.org/2655733003 > > Cr-Commit-Position: refs/heads/master@{#43000} > > Committed: https://chromium.googlesource.com/v8/v8/+/17c2dd388697da626224c371c8181d20d2016d82 > > TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Review-Url: https://codereview.chromium.org/2680923003 > Cr-Commit-Position: refs/heads/master@{#43011} > Committed: https://chromium.googlesource.com/v8/v8/+/ece4e54a31ac76ee9c450270d65270562db716e1 TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2679953003 Cr-Commit-Position: refs/heads/master@{#43012}
2017-02-07 20:42:03 +00:00
B(LdaImmutableCurrentContextSlot), U8(5),
[Interpreter] Remove all Ldr style bytecodes and replace with Star lookahead. We seem to get some small wins from avoiding the Ldr bytecodes, probably due to reduced icache pressure since there are less bytecode handlers. Replace the Ldr bytecodes with Star lookahead inlined into the Lda versions. Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and LdaCurrentContextSlot BUG=v8:4280 Review-Url: https://codereview.chromium.org/2489513005 Cr-Commit-Position: refs/heads/master@{#40883}
2016-11-10 10:41:48 +00:00
/* 106 E> */ B(ToName), R(7),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaConstant), U8(4),
[Interpreter] Introduce strict equality bytecode that does not collect feedback. Some of the StrictEquality comparisons do not require feedback (for ex: in try-finally, generators). This cl introduces StrictEqualityNoFeedback bytecode to be used in such cases. With this change, we no longer have to check if the type feedback slot is valid in compare bytecode handlers. This is the first step in reworking the compare bytecode handler to avoid duplicate checks when collecting feedback and when performing the operation. BUG=v8:4280 Change-Id: Ia650fd43c0466b8625d3ce98c39ed1073ba42a6b Reviewed-on: https://chromium-review.googlesource.com/455778 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#44020}
2017-03-22 11:08:18 +00:00
B(TestEqualStrictNoFeedback), R(7),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Mov), R(4), R(6),
[Interpreter] Move ToBoolean elision in BytecodeGenerator. Move the ToBoolean elision in the BytecodeGenerator instead of the peephole optimizer. Adds a TypeHint mechanism to the ExpressionResult to enable passing of type hints through the ast visitor. BUG=v8:6194 Change-Id: Ic55506ba11b213f7459250004d3f18cab04ee9b3 Reviewed-on: https://chromium-review.googlesource.com/467208 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44415}
2017-04-05 15:40:27 +00:00
B(JumpIfFalse), U8(7),
[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::kThrowStaticPrototypeError), R(0), U8(0),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(CreateClosure), U8(5), U8(4), U8(2),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Star), R(8),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(StaDataPropertyInLiteral), R(6), R(7), U8(3), U8(7),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessorWithCheck), R(4), U8(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(CallRuntime), U16(Runtime::kToFastProperties), R(4), 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(Star), R(0),
[interpreter] Filter expression positions at source. With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:32:33 +00:00
B(Star), R(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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(LdaUndefined),
/* 129 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 ["a"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["b"],
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["prototype"],
[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
SHARED_FUNCTION_INFO_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: [
]
---
snippet: "
var count = 0;
class C { constructor() { count++; }}
return new C();
"
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +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
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
bytecode array length: 64
[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(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(PushContext), R(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(LdaTheHole),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +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
/* 30 E> */ B(StackCheck),
/* 46 S> */ B(LdaZero),
[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
/* 46 E> */ 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(LdaTheHole),
B(Star), R(0),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
/* 49 S> */ B(CreateClosure), U8(0), U8(2), U8(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(Star), R(4),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[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(5),
[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
B(LdaSmi), I8(49),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Star), R(7),
[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
B(LdaSmi), I8(86),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(Star), R(8),
B(Mov), R(4), R(6),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(4),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
B(Star), R(5),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(4), U8(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(CallRuntime), U16(Runtime::kToFastProperties), R(4), 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(Star), R(0),
[Interpreter] Preserve source positions in peephole optimizer. The original peephole optimizer logic in the BytecodeArrayBuilder did not respect source positions as it was written before there were bytecode source positions. This led to some minor differences to FCG and was problematic when combined with pending bytecode optimizations. This change makes the new peephole optimizer fully respect source positions. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1998203002 Cr-Commit-Position: refs/heads/master@{#36439}
2016-05-23 13:31:53 +00:00
B(Star), R(1),
Wrap ClassLiterals in DoExpressions instead of giving them BlockScopes. This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
2016-07-25 19:16:21 +00:00
B(Star), R(2),
[ignition] Eliminate hole checks where statically possible for loads and stores Move hole check logic from full-codegen into scope analysis, and store the "needs hole check" bit on VariableProxy. This makes it easy to re-use in any backend: it will be trivial to extend the use of this logic in, e.g., full-codegen variable stores. While changing the signatures of the variable loading/storing methods in Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these are not part of AST visiting. BUG=v8:5460 Review-Url: https://chromiumcodereview.appspot.com/2411873004 Cr-Commit-Position: refs/heads/master@{#40479}
2016-10-20 17:31:36 +00:00
/* 87 S> */ B(Nop),
[Ignition] Rename New and NewWithSpread bytecodes. Rename to Construct and ConstructWithSpread, to match the names of the JSOperators used. Unfortunately, I can't find a way for auto-formatting to stay happy unless we change the indentation for the whole BYTECODE_LIST macro. Review-Url: https://codereview.chromium.org/2663963003 Cr-Commit-Position: refs/heads/master@{#42840}
2017-02-01 09:04:04 +00:00
/* 94 E> */ B(Construct), R(2), R(0), U8(0), 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
/* 103 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
SHARED_FUNCTION_INFO_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: [
]
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
---
snippet: "
(class {})
class E { static name () {}}
"
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +00:00
frame size: 10
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
parameter count: 1
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
bytecode array length: 102
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
bytecodes: [
B(LdaTheHole),
B(Star), R(3),
/* 30 E> */ B(StackCheck),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
/* 35 S> */ B(CreateClosure), U8(0), U8(2), U8(2),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(4),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(5),
[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
B(LdaSmi), I8(35),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(7),
[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
B(LdaSmi), I8(43),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(Star), R(8),
B(Mov), R(4), R(6),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(4),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(5),
B(CallRuntime), U16(Runtime::kToFastProperties), R(4), U8(1),
B(Star), R(1),
B(LdaTheHole),
B(Star), R(0),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
/* 45 S> */ B(CreateClosure), U8(1), U8(3), U8(2),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(4),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(5),
[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
B(LdaSmi), I8(45),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(7),
[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
B(LdaSmi), I8(73),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(Star), R(8),
B(Mov), R(4), R(6),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(4),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(5),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaConstant), U8(2),
[ignition] Avoid unnecessary ToName calls in VisitClassLiteralProperties R=rmcilroy@chromium.org BUG=v8:5799 Review-Url: https://codereview.chromium.org/2612903002 Cr-Commit-Position: refs/heads/master@{#42098}
2017-01-05 18:25:25 +00:00
B(Star), R(7),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(CreateClosure), U8(3), U8(4), U8(2),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(8),
[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
B(LdaSmi), I8(2),
[runtime] Collect IC feedback in DefineDataPropertyInLiteral. Add a feedback vector slot for computed property names in object and class literals. Introduce new slot kind for storing computed property names. Change StaDataPropertyInLiteral to use the accumulator (again), so we don't exceed Bytecodes::kMaxOperands. We assume that most computed property names are symbols. Therefore we should see performance improvements, even if we deal with monomorphic ICs only. This CL only collects feedback but does not use it in Reduce() yet. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2587393006 Cr-Commit-Position: refs/heads/master@{#42082}
2017-01-05 07:30:01 +00:00
B(Star), R(9),
B(Ldar), R(8),
[FeedbackVector] Infrastructure for literal arrays in the vector. This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
B(StaDataPropertyInLiteral), R(6), R(7), U8(1), U8(5),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(CallRuntime), U16(Runtime::kToFastProperties), R(4), U8(1),
B(Star), R(0),
B(Star), R(2),
B(Star), R(3),
B(LdaUndefined),
/* 74 S> */ B(Return),
]
constant pool: [
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name"],
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
Reference in New Issue Copy Permalink