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

35 lines
704 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] Replace BytecodeRegisterAllocator with a simple bump pointer. There are only a few occasions where we allocate a register in an outer expression allocation scope, which makes the costly free-list approach of the BytecodeRegisterAllocator unecessary. This CL replaces all occurrences with moves to the accumulator and stores to a register allocated in the correct scope. By doing this, we can simplify the BytecodeRegisterAllocator to be a simple bump-pointer allocator with registers released in the same order as allocated. The following changes are also made: - Make BytecodeRegisterOptimizer able to use registers which have been unallocated, but not yet reused - Remove RegisterExpressionResultScope and rename AccumulatorExpressionResultScope to ValueExpressionResultScope - Introduce RegisterList to represent consecutive register allocations, and use this for operands to call bytecodes. By avoiding the free-list handling, this gives another couple of percent on CodeLoad. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2369873002 Cr-Commit-Position: refs/heads/master@{#39905}
2016-09-30 09:02:59 +00:00
frame size: 2
[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
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
bytecode array length: 22
[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),
Reland: [TypeFeedbackVector] Store optimized code in the vector Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 Reviewed-on: https://chromium-review.googlesource.com/494487 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45084}
2017-05-03 15:59:47 +00:00
/* 34 S> */ B(CreateObjectLiteral), U8(0), U8(3), U8(1), R(1),
[interpreter] Add register output to ObjectLiteral Avoids the always generated Star bytecodes after ObjectLiteral. BUG=v4:4820 LOG=n Review-Url: https://codereview.chromium.org/2216023003 Cr-Commit-Position: refs/heads/master@{#38480}
2016-08-09 10:30:03 +00:00
B(Ldar), R(1),
[Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. There are only a few occasions where we allocate a register in an outer expression allocation scope, which makes the costly free-list approach of the BytecodeRegisterAllocator unecessary. This CL replaces all occurrences with moves to the accumulator and stores to a register allocated in the correct scope. By doing this, we can simplify the BytecodeRegisterAllocator to be a simple bump-pointer allocator with registers released in the same order as allocated. The following changes are also made: - Make BytecodeRegisterOptimizer able to use registers which have been unallocated, but not yet reused - Remove RegisterExpressionResultScope and rename AccumulatorExpressionResultScope to ValueExpressionResultScope - Introduce RegisterList to represent consecutive register allocations, and use this for operands to call bytecodes. By avoiding the free-list handling, this gives another couple of percent on CodeLoad. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2369873002 Cr-Commit-Position: refs/heads/master@{#39905}
2016-09-30 09:02:59 +00:00
B(ToObject), R(1),
[interpreter] Add CreateWithContext bytecode Generates a JSCreateWithContext node for TurboFan to optimize. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2255793002 Cr-Commit-Position: refs/heads/master@{#38723}
2016-08-18 15:14:43 +00:00
B(Ldar), R(closure),
[Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. There are only a few occasions where we allocate a register in an outer expression allocation scope, which makes the costly free-list approach of the BytecodeRegisterAllocator unecessary. This CL replaces all occurrences with moves to the accumulator and stores to a register allocated in the correct scope. By doing this, we can simplify the BytecodeRegisterAllocator to be a simple bump-pointer allocator with registers released in the same order as allocated. The following changes are also made: - Make BytecodeRegisterOptimizer able to use registers which have been unallocated, but not yet reused - Remove RegisterExpressionResultScope and rename AccumulatorExpressionResultScope to ValueExpressionResultScope - Introduce RegisterList to represent consecutive register allocations, and use this for operands to call bytecodes. By avoiding the free-list handling, this gives another couple of percent on CodeLoad. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2369873002 Cr-Commit-Position: refs/heads/master@{#39905}
2016-09-30 09:02:59 +00:00
B(CreateWithContext), R(1), 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),
[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(PopContext), R(0),
/* 62 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
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
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