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

46 lines
686 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: "
return new.target;
"
Use Variable::binding_needs_init() to determine hole initialization The old code was using VariableMode, but that signal is both over-pessimistic (some CONST and LET variables need no hole-initialization) and inconsistent with other uses of the InitializationFlag enum (such as %LoadLookupSlot). This changes no observable behavior, but removes unnecessary hole initialization and hole checks in a few places, including block-scoped function declarations, super property lookups, and new.target. R=bmeurer@chromium.org, neis@chromium.org Review-Url: https://codereview.chromium.org/2201193004 Cr-Commit-Position: refs/heads/master@{#38395}
2016-08-05 17:50:08 +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] Fix destroyed new.target register use. This fixes a corner-case where the bytecode was using the <new.target> register directly without going through the local variable. The value might be clobbered because the deoptimizer doesn't properly restore the value. The label will causes bytecode pipeline to be flushed and hence ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-645103 BUG=chromium:645103 Review-Url: https://codereview.chromium.org/2325133002 Cr-Commit-Position: refs/heads/master@{#39306}
2016-09-09 12:19:48 +00:00
bytecode array length: 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
bytecodes: [
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
B(Mov), R(new_target), R(0),
[ignition] Fix register flushing performance issue In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
2017-06-09 09:26:27 +00:00
B(Ldar), R(0),
[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),
Use Variable::binding_needs_init() to determine hole initialization The old code was using VariableMode, but that signal is both over-pessimistic (some CONST and LET variables need no hole-initialization) and inconsistent with other uses of the InitializationFlag enum (such as %LoadLookupSlot). This changes no observable behavior, but removes unnecessary hole initialization and hole checks in a few places, including block-scoped function declarations, super property lookups, and new.target. R=bmeurer@chromium.org, neis@chromium.org Review-Url: https://codereview.chromium.org/2201193004 Cr-Commit-Position: refs/heads/master@{#38395}
2016-08-05 17:50:08 +00:00
/* 34 S> */ B(Ldar), R(0),
[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
/* 52 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
]
handlers: [
]
---
snippet: "
new.target;
"
Use Variable::binding_needs_init() to determine hole initialization The old code was using VariableMode, but that signal is both over-pessimistic (some CONST and LET variables need no hole-initialization) and inconsistent with other uses of the InitializationFlag enum (such as %LoadLookupSlot). This changes no observable behavior, but removes unnecessary hole initialization and hole checks in a few places, including block-scoped function declarations, super property lookups, and new.target. R=bmeurer@chromium.org, neis@chromium.org Review-Url: https://codereview.chromium.org/2201193004 Cr-Commit-Position: refs/heads/master@{#38395}
2016-08-05 17:50:08 +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] Fix destroyed new.target register use. This fixes a corner-case where the bytecode was using the <new.target> register directly without going through the local variable. The value might be clobbered because the deoptimizer doesn't properly restore the value. The label will causes bytecode pipeline to be flushed and hence ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-645103 BUG=chromium:645103 Review-Url: https://codereview.chromium.org/2325133002 Cr-Commit-Position: refs/heads/master@{#39306}
2016-09-09 12:19:48 +00:00
bytecode array length: 8
[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] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
B(Mov), R(new_target), R(0),
[ignition] Fix register flushing performance issue In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
2017-06-09 09:26:27 +00:00
B(Ldar), R(0),
[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),
Use Variable::binding_needs_init() to determine hole initialization The old code was using VariableMode, but that signal is both over-pessimistic (some CONST and LET variables need no hole-initialization) and inconsistent with other uses of the InitializationFlag enum (such as %LoadLookupSlot). This changes no observable behavior, but removes unnecessary hole initialization and hole checks in a few places, including block-scoped function declarations, super property lookups, and new.target. R=bmeurer@chromium.org, neis@chromium.org Review-Url: https://codereview.chromium.org/2201193004 Cr-Commit-Position: refs/heads/master@{#38395}
2016-08-05 17:50:08 +00:00
/* 34 S> */ B(LdaUndefined),
[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
/* 46 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: [
]
handlers: [
]
Reference in New Issue Copy Permalink