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

45 lines
911 B
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.
#
---
pool type: mixed
execute: yes
wrap: yes
---
snippet: "
with ({x:42}) { return x; }
"
frame size: 5
parameter count: 1
[Interpreter] Fixes a bug when popping context to correct level on break/continue. The current implementation does not consider the case when the context of the control scope and the current context differ. It is possible that they are different in some cases for example: with statements. This cl fixes this. BUG=v8:4280,v8:4680 LOG=N Review URL: https://codereview.chromium.org/1768123002 Cr-Commit-Position: refs/heads/master@{#34609}
2016-03-09 11:04:45 +00:00
bytecode array length: 45
[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: [
B(CallRuntime), U16(Runtime::kNewFunctionContext), R(closure), U8(1),
B(PushContext), R(0),
B(Ldar), R(this),
B(StaContextSlot), R(context), U8(4),
B(CreateMappedArguments),
B(StaContextSlot), R(context), U8(5),
B(Ldar), R(new_target),
B(StaContextSlot), R(context), U8(6),
B(StackCheck),
Don't do any special normalization if a boilerplate contains function literals. This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,: function.prototype = { method: function() { ... } } Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore. This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression. BUG=chromium:593008 LOG=n Review URL: https://codereview.chromium.org/1772423002 Cr-Commit-Position: refs/heads/master@{#34602}
2016-03-08 22:13:23 +00:00
B(CreateObjectLiteral), U8(0), U8(0), U8(5),
[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
B(Star), R(2),
B(ToObject),
B(Star), R(3),
B(Ldar), R(closure),
B(Star), R(4),
B(CallRuntime), U16(Runtime::kPushWithContext), R(3), U8(2),
B(PushContext), R(1),
B(LdaLookupSlot), U8(1),
B(Return),
]
constant pool: [
InstanceType::FIXED_ARRAY_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
]
handlers: [
]
Reference in New Issue Copy Permalink