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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

32 lines
612 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.
#
---
wrap: yes
---
snippet: "
with ({x:42}) { return x; }
"
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
frame size: 1
[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] Store CreateObjectLiteral's result into the accumulator. As opposed to the register. For subtle reasons, this fixes a deoptimizer bug with handling return values in lazy deopt. Since the return values can now only overwrite the accumulator, there is no danger of overwriting a captured object that might be later used (since there is no "later"). Bug: chromium:902608 Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942 Reviewed-on: https://chromium-review.googlesource.com/c/1325901 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57349}
2018-11-08 08:55:43 +00:00
bytecode array length: 15
[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
/* 30 E> */ B(StackCheck),
[interpreter] Store CreateObjectLiteral's result into the accumulator. As opposed to the register. For subtle reasons, this fixes a deoptimizer bug with handling return values in lazy deopt. Since the return values can now only overwrite the accumulator, there is no danger of overwriting a captured object that might be later used (since there is no "later"). Bug: chromium:902608 Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942 Reviewed-on: https://chromium-review.googlesource.com/c/1325901 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57349}
2018-11-08 08:55:43 +00:00
/* 34 S> */ B(CreateObjectLiteral), U8(0), U8(0), U8(41),
[Interpreter] Allocate context registers as temporary registers. Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 15:48:27 +00:00
B(ToObject), R(0),
B(CreateWithContext), R(0), 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(PushContext), R(0),
Store the ScopeInfo in WithContexts This will allow for chaining ScopeInfos together to form the same chains as contexts chains currently do. BUG=v8:5215 R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2314483002 Cr-Commit-Position: refs/heads/master@{#39192}
2016-09-06 08:27:36 +00:00
/* 50 S> */ B(LdaLookupSlot), U8(2),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 59 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: [
[runtime][parser] Use ArrayBoilerplateDescription all the way * Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 18:34:09 +00:00
OBJECT_BOILERPLATE_DESCRIPTION_TYPE,
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_INFO_TYPE,
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["x"],
[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: [
]
Reference in New Issue Copy Permalink