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

762 lines
18 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.
#
---
pool type: mixed
execute: yes
wrap: yes
---
snippet: "
for (var p of [0, 1, 2]) {}
"
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
frame size: 16
[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
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
bytecode array length: 347
[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(StackCheck),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(LdaUndefined),
B(Star), R(4),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LdaZero),
B(Star), R(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Mov), R(context), R(11),
B(Mov), R(context), R(12),
[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(CreateArrayLiteral), U8(0), U8(0), U8(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
[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(LdaConstant), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(KeyedLoadIC), R(14), U8(3),
B(Star), R(13),
B(Call), R(13), R(14), U8(1), U8(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
B(Star), R(1),
B(Ldar), R(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(15),
B(LoadIC), R(15), U8(2), U8(7),
B(Star), R(14),
B(Call), R(14), R(15), U8(1), 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),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(13), U8(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
B(LogicalNot),
B(JumpIfFalse), U8(11),
B(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(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
B(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(LoadIC), R(13), U8(3), U8(9),
B(JumpIfToBooleanTrue), U8(28),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(3),
[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(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(LoadIC), R(13), U8(4), U8(11),
[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(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(4),
[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(StackCheck),
B(Ldar), R(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(7),
B(LdaZero),
B(Star), R(3),
B(Jump), U8(-70),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Jump), U8(47),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(LdaConstant), U8(5),
B(Star), R(13),
B(Ldar), R(closure),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(13), U8(3),
B(Star), R(12),
B(PushContext), R(8),
B(Ldar), R(3),
B(Star), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(13),
B(JumpIfFalse), U8(6),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(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
B(Star), R(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(LdaContextSlot), R(context), U8(4),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kReThrow), R(13), U8(1),
B(PopContext), R(8),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(-1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(9),
B(Jump), U8(7),
B(Star), R(10),
B(LdaZero),
B(Star), R(9),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Star), R(11),
B(Ldar), R(3),
B(Star), R(12),
B(LdaZero),
B(TestEqualStrict), R(12),
B(JumpIfTrue), U8(9),
B(Ldar), R(1),
B(Star), R(12),
B(LdaUndefined),
B(TestEqualStrict), R(12),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LogicalNot),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalseConstant), U8(9),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(1),
B(Star), R(12),
B(LoadIC), R(12), U8(6), U8(13),
B(Star), R(5),
B(Star), R(12),
B(LdaNull),
B(TestEqual), R(12),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(124),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(3),
B(Star), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalse), U8(79),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(5),
B(TypeOf),
B(Star), R(12),
B(LdaConstant), U8(7),
B(TestEqualStrict), R(12),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(18),
Add checks for detached ArrayBuffers to ArrayBuffer.prototype.slice These checks ensure that a TypeError is thrown, per spec, rather than a runtime assert failure. BUG=v8:4964 R=adamk LOG=Y Review-Url: https://codereview.chromium.org/1929123002 Cr-Commit-Position: refs/heads/master@{#35885}
2016-04-28 22:49:44 +00:00
B(Wide), B(LdaSmi), U16(130),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaConstant), U8(8),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kNewTypeError), R(12), U8(2),
B(Throw),
B(Mov), R(context), R(12),
B(Ldar), R(5),
B(Star), R(13),
B(Ldar), R(1),
B(Star), R(14),
B(CallRuntime), U16(Runtime::k_Call), R(13), U8(2),
B(Jump), U8(30),
B(Star), R(14),
B(LdaConstant), U8(5),
B(Star), R(13),
B(Ldar), R(closure),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(13), U8(3),
B(Star), R(12),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Ldar), R(12),
B(PushContext), R(8),
B(PopContext), R(8),
B(Jump), U8(37),
B(Ldar), R(5),
B(Star), R(12),
B(Ldar), R(1),
B(Star), R(13),
B(CallRuntime), U16(Runtime::k_Call), R(12), U8(2),
B(Star), R(6),
B(Star), R(12),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(12), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(11),
B(Ldar), R(6),
B(Star), R(12),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(12), U8(1),
B(CallRuntime), U16(Runtime::kInterpreterSetPendingMessage), R(11), U8(1),
B(LdaZero),
B(TestEqualStrict), R(9),
B(JumpIfTrue), U8(4),
B(Jump), U8(5),
B(Ldar), R(10),
B(ReThrow),
[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(LdaUndefined),
B(Return),
]
constant pool: [
InstanceType::FIXED_ARRAY_TYPE,
InstanceType::SYMBOL_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
kInstanceTypeDontCare,
[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: [
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[10, 152, 158],
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
[13, 105, 107],
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[250, 263, 265],
[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
]
---
snippet: "
var x = 'potatoes';
for (var p of x) { return p; }
"
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
frame size: 17
[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
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
bytecode array length: 363
[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(StackCheck),
B(LdaConstant), U8(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(7),
B(LdaUndefined),
B(Star), R(4),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LdaZero),
B(Star), R(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Mov), R(context), R(12),
B(Mov), R(context), R(13),
B(Ldar), R(7),
B(Star), R(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
B(LdaConstant), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(KeyedLoadIC), R(15), U8(3),
B(Star), R(14),
B(Call), R(14), R(15), U8(1), U8(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
B(Star), R(1),
B(Ldar), R(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(16),
B(LoadIC), R(16), U8(2), U8(7),
B(Star), R(15),
B(Call), R(15), R(16), U8(1), 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),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(14), U8(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
B(LogicalNot),
B(JumpIfFalse), U8(11),
B(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(14), U8(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
B(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(LoadIC), R(14), U8(3), U8(9),
B(JumpIfToBooleanTrue), U8(32),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(3),
[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(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(LoadIC), R(14), U8(4), U8(11),
[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(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(4),
[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(StackCheck),
B(Ldar), R(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(8),
B(Star), R(11),
B(LdaZero),
B(Star), R(10),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Jump), U8(63),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Jump), U8(-74),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Jump), U8(47),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(15),
B(LdaConstant), U8(5),
B(Star), R(14),
B(Ldar), R(closure),
B(Star), R(16),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(14), U8(3),
B(Star), R(13),
B(PushContext), R(9),
B(Ldar), R(3),
B(Star), R(14),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(14),
B(JumpIfFalse), U8(6),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(3),
B(LdaContextSlot), R(context), U8(4),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Star), R(14),
B(CallRuntime), U16(Runtime::kReThrow), R(14), U8(1),
B(PopContext), R(9),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(-1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(10),
B(Jump), U8(8),
B(Star), R(11),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(10),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Star), R(12),
B(Ldar), R(3),
B(Star), R(13),
B(LdaZero),
B(TestEqualStrict), R(13),
B(JumpIfTrue), U8(9),
B(Ldar), R(1),
B(Star), R(13),
B(LdaUndefined),
B(TestEqualStrict), R(13),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LogicalNot),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalseConstant), U8(9),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(1),
B(Star), R(13),
B(LoadIC), R(13), U8(6), U8(13),
B(Star), R(5),
B(Star), R(13),
B(LdaNull),
B(TestEqual), R(13),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(124),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(3),
B(Star), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalse), U8(79),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(5),
B(TypeOf),
B(Star), R(13),
B(LdaConstant), U8(7),
B(TestEqualStrict), R(13),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(18),
Add checks for detached ArrayBuffers to ArrayBuffer.prototype.slice These checks ensure that a TypeError is thrown, per spec, rather than a runtime assert failure. BUG=v8:4964 R=adamk LOG=Y Review-Url: https://codereview.chromium.org/1929123002 Cr-Commit-Position: refs/heads/master@{#35885}
2016-04-28 22:49:44 +00:00
B(Wide), B(LdaSmi), U16(130),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaConstant), U8(8),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(CallRuntime), U16(Runtime::kNewTypeError), R(13), U8(2),
B(Throw),
B(Mov), R(context), R(13),
B(Ldar), R(5),
B(Star), R(14),
B(Ldar), R(1),
B(Star), R(15),
B(CallRuntime), U16(Runtime::k_Call), R(14), U8(2),
B(Jump), U8(30),
B(Star), R(15),
B(LdaConstant), U8(5),
B(Star), R(14),
B(Ldar), R(closure),
B(Star), R(16),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(14), U8(3),
B(Star), R(13),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Ldar), R(13),
B(PushContext), R(9),
B(PopContext), R(9),
B(Jump), U8(37),
B(Ldar), R(5),
B(Star), R(13),
B(Ldar), R(1),
B(Star), R(14),
B(CallRuntime), U16(Runtime::k_Call), R(13), U8(2),
B(Star), R(6),
B(Star), R(13),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(13), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(11),
B(Ldar), R(6),
B(Star), R(13),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(1),
B(CallRuntime), U16(Runtime::kInterpreterSetPendingMessage), R(12), U8(1),
B(LdaZero),
B(TestEqualStrict), R(10),
B(JumpIfTrue), U8(10),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(10),
B(JumpIfTrue), U8(7),
B(Jump), U8(8),
B(Ldar), R(11),
[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(Return),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(11),
B(ReThrow),
[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(LdaUndefined),
B(Return),
]
constant pool: [
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::SYMBOL_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
kInstanceTypeDontCare,
[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: [
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[14, 158, 164],
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
[17, 111, 113],
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[257, 270, 272],
[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
]
---
snippet: "
for (var x of [10, 20, 30]) {
if (x == 10) continue;
if (x == 20) break;
}
"
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
frame size: 16
[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
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
bytecode array length: 369
[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(StackCheck),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(LdaUndefined),
B(Star), R(4),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LdaZero),
B(Star), R(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Mov), R(context), R(11),
B(Mov), R(context), R(12),
[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(CreateArrayLiteral), U8(0), U8(0), U8(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
[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(LdaConstant), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(KeyedLoadIC), R(14), U8(3),
B(Star), R(13),
B(Call), R(13), R(14), U8(1), U8(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
B(Star), R(1),
B(Ldar), R(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(15),
B(LoadIC), R(15), U8(2), U8(7),
B(Star), R(14),
B(Call), R(14), R(15), U8(1), 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),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(13), U8(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
B(LogicalNot),
B(JumpIfFalse), U8(11),
B(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(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
B(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(LoadIC), R(13), U8(3), U8(9),
B(JumpIfToBooleanTrue), U8(50),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(3),
[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(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(LoadIC), R(13), U8(4), U8(11),
[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(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(4),
[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(StackCheck),
B(Ldar), R(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(7),
B(Star), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(10),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqual), R(13),
[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(JumpIfFalse), U8(4),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Jump), U8(-75),
B(Ldar), R(7),
B(Star), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(20),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqual), R(13),
[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(JumpIfFalse), U8(4),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Jump), U8(7),
B(LdaZero),
B(Star), R(3),
B(Jump), U8(-92),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Jump), U8(47),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(LdaConstant), U8(5),
B(Star), R(13),
B(Ldar), R(closure),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(13), U8(3),
B(Star), R(12),
B(PushContext), R(8),
B(Ldar), R(3),
B(Star), R(13),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(13),
B(JumpIfFalse), U8(6),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(3),
B(LdaContextSlot), R(context), U8(4),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kReThrow), R(13), U8(1),
B(PopContext), R(8),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(-1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(9),
B(Jump), U8(7),
B(Star), R(10),
B(LdaZero),
B(Star), R(9),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Star), R(11),
B(Ldar), R(3),
B(Star), R(12),
B(LdaZero),
B(TestEqualStrict), R(12),
B(JumpIfTrue), U8(9),
B(Ldar), R(1),
B(Star), R(12),
B(LdaUndefined),
B(TestEqualStrict), R(12),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LogicalNot),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalseConstant), U8(9),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(1),
B(Star), R(12),
B(LoadIC), R(12), U8(6), U8(13),
B(Star), R(5),
B(Star), R(12),
B(LdaNull),
B(TestEqual), R(12),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(124),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(3),
B(Star), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalse), U8(79),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(5),
B(TypeOf),
B(Star), R(12),
B(LdaConstant), U8(7),
B(TestEqualStrict), R(12),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(18),
Add checks for detached ArrayBuffers to ArrayBuffer.prototype.slice These checks ensure that a TypeError is thrown, per spec, rather than a runtime assert failure. BUG=v8:4964 R=adamk LOG=Y Review-Url: https://codereview.chromium.org/1929123002 Cr-Commit-Position: refs/heads/master@{#35885}
2016-04-28 22:49:44 +00:00
B(Wide), B(LdaSmi), U16(130),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaConstant), U8(8),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(CallRuntime), U16(Runtime::kNewTypeError), R(12), U8(2),
B(Throw),
B(Mov), R(context), R(12),
B(Ldar), R(5),
B(Star), R(13),
B(Ldar), R(1),
B(Star), R(14),
B(CallRuntime), U16(Runtime::k_Call), R(13), U8(2),
B(Jump), U8(30),
B(Star), R(14),
B(LdaConstant), U8(5),
B(Star), R(13),
B(Ldar), R(closure),
B(Star), R(15),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(13), U8(3),
B(Star), R(12),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Ldar), R(12),
B(PushContext), R(8),
B(PopContext), R(8),
B(Jump), U8(37),
B(Ldar), R(5),
B(Star), R(12),
B(Ldar), R(1),
B(Star), R(13),
B(CallRuntime), U16(Runtime::k_Call), R(12), U8(2),
B(Star), R(6),
B(Star), R(12),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(12), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(11),
B(Ldar), R(6),
B(Star), R(12),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(12), U8(1),
B(CallRuntime), U16(Runtime::kInterpreterSetPendingMessage), R(11), U8(1),
B(LdaZero),
B(TestEqualStrict), R(9),
B(JumpIfTrue), U8(4),
B(Jump), U8(5),
B(Ldar), R(10),
B(ReThrow),
[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(LdaUndefined),
B(Return),
]
constant pool: [
InstanceType::FIXED_ARRAY_TYPE,
InstanceType::SYMBOL_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
kInstanceTypeDontCare,
[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: [
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[10, 174, 180],
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
[13, 127, 129],
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[272, 285, 287],
[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
]
---
snippet: "
var x = { 'a': 1, 'b': 2 };
for (x['a'] of [1,2,3]) { return x['a']; }
"
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
frame size: 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
parameter count: 1
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
bytecode array length: 379
[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(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] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(8),
B(Star), R(6),
B(LdaUndefined),
B(Star), R(3),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LdaZero),
B(Star), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Mov), R(context), R(10),
B(Mov), R(context), R(11),
[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(CreateArrayLiteral), U8(1), U8(1), U8(3),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
[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(LdaConstant), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(KeyedLoadIC), R(13), U8(3),
B(Star), R(12),
B(Call), R(12), R(13), U8(1), U8(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
B(Star), R(0),
B(Ldar), R(0),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(14),
B(LoadIC), R(14), U8(3), U8(7),
B(Star), R(13),
B(Call), R(13), R(14), U8(1), 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(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(12), U8(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
B(LogicalNot),
B(JumpIfFalse), U8(11),
B(Ldar), R(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(12), U8(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
B(Ldar), R(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
B(LoadIC), R(12), U8(4), U8(9),
B(JumpIfToBooleanTrue), U8(42),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(2),
B(Ldar), R(6),
B(Star), R(12),
[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(Ldar), R(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(LoadIC), R(13), U8(5), U8(11),
B(StoreICSloppy), R(12), U8(6), U8(13),
B(Ldar), R(3),
[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(StackCheck),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(6),
B(Star), R(12),
B(LoadIC), R(12), U8(6), U8(15),
B(Star), R(9),
B(LdaZero),
B(Star), R(8),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Jump), U8(63),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Jump), U8(-84),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Jump), U8(47),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(13),
B(LdaConstant), U8(7),
B(Star), R(12),
B(Ldar), R(closure),
B(Star), R(14),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(12), U8(3),
B(Star), R(11),
B(PushContext), R(7),
[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(Ldar), R(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(2),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(12),
B(JumpIfFalse), U8(6),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(2),
B(LdaContextSlot), R(context), U8(4),
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
B(Star), R(12),
B(CallRuntime), U16(Runtime::kReThrow), R(12), U8(1),
B(PopContext), R(7),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(-1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(8),
B(Jump), U8(8),
B(Star), R(9),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(8),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Star), R(10),
B(Ldar), R(2),
B(Star), R(11),
B(LdaZero),
B(TestEqualStrict), R(11),
B(JumpIfTrue), U8(9),
B(Ldar), R(0),
B(Star), R(11),
B(LdaUndefined),
B(TestEqualStrict), R(11),
Implement iterator finalization in array destructuring. We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
2016-03-10 09:33:29 +00:00
B(LogicalNot),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalseConstant), U8(11),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(0),
B(Star), R(11),
B(LoadIC), R(11), U8(8), U8(17),
B(Star), R(4),
B(Star), R(11),
B(LdaNull),
B(TestEqual), R(11),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(124),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(2),
B(Star), R(11),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(11),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(JumpIfFalse), U8(79),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(4),
B(TypeOf),
B(Star), R(11),
B(LdaConstant), U8(9),
B(TestEqualStrict), R(11),
B(JumpIfFalse), U8(4),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(Jump), U8(18),
Add checks for detached ArrayBuffers to ArrayBuffer.prototype.slice These checks ensure that a TypeError is thrown, per spec, rather than a runtime assert failure. BUG=v8:4964 R=adamk LOG=Y Review-Url: https://codereview.chromium.org/1929123002 Cr-Commit-Position: refs/heads/master@{#35885}
2016-04-28 22:49:44 +00:00
B(Wide), B(LdaSmi), U16(130),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(11),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaConstant), U8(10),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Star), R(12),
B(CallRuntime), U16(Runtime::kNewTypeError), R(11), U8(2),
B(Throw),
B(Mov), R(context), R(11),
B(Ldar), R(4),
B(Star), R(12),
B(Ldar), R(0),
B(Star), R(13),
B(CallRuntime), U16(Runtime::k_Call), R(12), U8(2),
B(Jump), U8(30),
B(Star), R(13),
B(LdaConstant), U8(7),
B(Star), R(12),
B(Ldar), R(closure),
B(Star), R(14),
B(CallRuntime), U16(Runtime::kPushCatchContext), R(12), U8(3),
B(Star), R(11),
B(CallRuntime), U16(Runtime::kInterpreterClearPendingMessage), R(0), U8(0),
B(Ldar), R(11),
B(PushContext), R(7),
B(PopContext), R(7),
B(Jump), U8(37),
B(Ldar), R(4),
B(Star), R(11),
B(Ldar), R(0),
B(Star), R(12),
B(CallRuntime), U16(Runtime::k_Call), R(11), U8(2),
B(Star), R(5),
B(Star), R(11),
[Interpreter] TurboFan implementation of intrinsics. Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call. BUG=v8:4822 LOG=y Review URL: https://codereview.chromium.org/1645763003 Cr-Commit-Position: refs/heads/master@{#34983}
2016-03-22 11:35:09 +00:00
B(InvokeIntrinsic), U16(Runtime::k_IsJSReceiver), R(11), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(JumpIfToBooleanFalse), U8(4),
B(Jump), U8(11),
B(Ldar), R(5),
B(Star), R(11),
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(11), U8(1),
B(CallRuntime), U16(Runtime::kInterpreterSetPendingMessage), R(10), U8(1),
B(LdaZero),
B(TestEqualStrict), R(8),
B(JumpIfTrue), U8(10),
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
B(LdaSmi), U8(1),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(TestEqualStrict), R(8),
B(JumpIfTrue), U8(7),
B(Jump), U8(8),
B(Ldar), R(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
B(Return),
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
B(Ldar), R(9),
B(ReThrow),
[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(LdaUndefined),
B(Return),
]
constant pool: [
InstanceType::FIXED_ARRAY_TYPE,
InstanceType::FIXED_ARRAY_TYPE,
InstanceType::SYMBOL_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
InstanceType::ONE_BYTE_INTERNALIZED_STRING_TYPE,
kInstanceTypeDontCare,
[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: [
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[18, 174, 180],
[Interpreter] Rebaseline ForOf bytecode generator tests. Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
2016-02-26 14:22:07 +00:00
[21, 127, 129],
Preserve exception message in iterator finalization. The parser uses a try-catch in order to record when the client of an iterator throws. The exception then used to get rethrown via 'throw', which unfortunately resulted in the original exception message object getting overwritten. This CL solves this as follows: - add a clear_pending_message flag to TryCatchStatement (set to true in normal cases), - set clear_pending_message to false for the TryCatchStatement used in iterator finalization - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call only when the flag is set, - replace 'throw' with '%ReThrow' in the iterator finalization code, thus reusing the (not-cleared) pending message R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4875 LOG=n Review URL: https://codereview.chromium.org/1842953003 Cr-Commit-Position: refs/heads/master@{#35226}
2016-04-04 08:14:57 +00:00
[273, 286, 288],
[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
]
Reference in New Issue Copy Permalink