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

243 lines
6.0 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.
#
---
wrap: yes
---
snippet: "
for (var p in null) {}
"
frame size: 2
parameter count: 1
bytecode array length: 3
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
B(LdaUndefined),
/* 57 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
]
handlers: [
]
---
snippet: "
for (var p in undefined) {}
"
frame size: 2
parameter count: 1
bytecode array length: 3
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
B(LdaUndefined),
/* 62 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
]
handlers: [
]
---
snippet: "
for (var p in undefined) {}
"
frame size: 2
parameter count: 1
bytecode array length: 3
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
B(LdaUndefined),
/* 62 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
]
handlers: [
]
---
snippet: "
var x = 'potatoes';
for (var p in x) { return p; }
"
frame size: 8
parameter count: 1
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
bytecode array length: 45
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
/* 42 S> */ B(LdaConstant), U8(0),
Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_ BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272083003 Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:11:19 +00:00
B(Star), R(0),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
/* 68 S> */ B(JumpIfUndefined), U8(38),
B(JumpIfNull), U8(36),
[interpreter] Put object in register for ToObject/ForInPrepare This gets rid of the Star bytecodes that were always dispatched to from ToObject. ToObject now outputs to register instead of to the accumulator and ForInPrepare gets the receiver object from an input register. BUG=v8:4820 LOG=n Review-Url: https://codereview.chromium.org/2189463006 Cr-Commit-Position: refs/heads/master@{#38177}
2016-07-29 11:14:55 +00:00
B(ToObject), R(3),
B(ForInPrepare), R(3), R(4),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
B(Star), R(7),
[turbofan] Remove special JSForInStep and JSForInDone. These JavaScript operators were special hacks to ensure that we always operate on Smis for the magic for-in index variable, but this never really worked in the OSR case, because the OsrValue for the index variable didn't have the proper information (that we have for the JSForInPrepare in the non-OSR case). Now that we have loop induction variable analysis and binary operation hints, we can just use JSLessThan and JSAdd instead with appropriate Smi hints, which handle the OSR case by inserting Smi checks (that are always true). Thanks to OSR deconstruction and loop peeling these Smi checks will be hoisted so they don't hurt the OSR case too much. Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since we have to lower it to JSLessThan to get the loop induction variable goodness. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289613002 Cr-Commit-Position: refs/heads/master@{#38968}
2016-08-29 08:47:12 +00:00
/* 63 S> */ B(ForInContinue), R(7), R(6),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
B(JumpIfFalse), U8(23),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(ForInNext), R(3), R(7), R(4), U8(4),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
B(JumpIfUndefined), U8(9),
Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_ BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272083003 Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:11:19 +00:00
B(Star), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 54 E> */ B(StackCheck),
B(Star), R(2),
[Interpreter] Preserve source positions in peephole optimizer. The original peephole optimizer logic in the BytecodeArrayBuilder did not respect source positions as it was written before there were bytecode source positions. This led to some minor differences to FCG and was problematic when combined with pending bytecode optimizations. This change makes the new peephole optimizer fully respect source positions. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1998203002 Cr-Commit-Position: refs/heads/master@{#36439}
2016-05-23 13:31:53 +00:00
/* 73 S> */ B(Nop),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 85 S> */ B(Return),
B(ForInStep), R(7),
B(Star), R(7),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
B(JumpLoop), U8(23), I8(0),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 85 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["potatoes"],
[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: [
]
---
snippet: "
var x = 0;
for (var p in [1,2,3]) { x += p; }
"
frame size: 9
parameter count: 1
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
bytecode array length: 56
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
/* 42 S> */ B(LdaZero),
Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_ BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272083003 Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:11:19 +00:00
B(Star), R(0),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 59 S> */ B(CreateArrayLiteral), U8(0), U8(4), U8(17),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
B(JumpIfUndefined), U8(46),
B(JumpIfNull), U8(44),
[interpreter] Put object in register for ToObject/ForInPrepare This gets rid of the Star bytecodes that were always dispatched to from ToObject. ToObject now outputs to register instead of to the accumulator and ForInPrepare gets the receiver object from an input register. BUG=v8:4820 LOG=n Review-Url: https://codereview.chromium.org/2189463006 Cr-Commit-Position: refs/heads/master@{#38177}
2016-07-29 11:14:55 +00:00
B(ToObject), R(3),
B(ForInPrepare), R(3), R(4),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
B(Star), R(7),
[turbofan] Remove special JSForInStep and JSForInDone. These JavaScript operators were special hacks to ensure that we always operate on Smis for the magic for-in index variable, but this never really worked in the OSR case, because the OsrValue for the index variable didn't have the proper information (that we have for the JSForInPrepare in the non-OSR case). Now that we have loop induction variable analysis and binary operation hints, we can just use JSLessThan and JSAdd instead with appropriate Smi hints, which handle the OSR case by inserting Smi checks (that are always true). Thanks to OSR deconstruction and loop peeling these Smi checks will be hoisted so they don't hurt the OSR case too much. Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since we have to lower it to JSLessThan to get the loop induction variable goodness. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289613002 Cr-Commit-Position: refs/heads/master@{#38968}
2016-08-29 08:47:12 +00:00
/* 54 S> */ B(ForInContinue), R(7), R(6),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
B(JumpIfFalse), U8(31),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(ForInNext), R(3), R(7), R(4), U8(6),
[Interpreter] Assign feedback slots for binary operations and use them in ignition. Assign feedback slots in the type feedback vector for binary operations. Update bytecode-generator to use these slots and add them as an operand to binary operations. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2209633002 Cr-Commit-Position: refs/heads/master@{#38408}
2016-08-08 01:15:22 +00:00
B(JumpIfUndefined), U8(17),
Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_ BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272083003 Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:11:19 +00:00
B(Star), R(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 45 E> */ B(StackCheck),
B(Star), R(2),
Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_ BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272083003 Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:11:19 +00:00
/* 70 S> */ B(Ldar), R(1),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 75 E> */ B(Add), R(0), U8(5),
Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_ BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272083003 Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:11:19 +00:00
B(Mov), R(0), R(8),
B(Star), R(0),
[interpreter] Filter expression positions at source. With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:32:33 +00:00
/* 72 E> */ B(ForInStep), R(7),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(7),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
B(JumpLoop), U8(31), I8(0),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 80 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
Do not use new struct type where unnecessary. We can use TUPLE2 or TUPLE3 for structs that do not need special handling by deoptimizer and compiler. This frees up a few instance types, so that adding the next few new structs will not cause ABI compatibility to break. R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2811183005 Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
TUPLE2_TYPE,
[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: [
]
---
snippet: "
var x = { 'a': 1, 'b': 2 };
for (x['a'] in [10, 20, 30]) {
if (x['a'] == 10) continue;
if (x['a'] == 20) break;
}
"
[Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. There are only a few occasions where we allocate a register in an outer expression allocation scope, which makes the costly free-list approach of the BytecodeRegisterAllocator unecessary. This CL replaces all occurrences with moves to the accumulator and stores to a register allocated in the correct scope. By doing this, we can simplify the BytecodeRegisterAllocator to be a simple bump-pointer allocator with registers released in the same order as allocated. The following changes are also made: - Make BytecodeRegisterOptimizer able to use registers which have been unallocated, but not yet reused - Remove RegisterExpressionResultScope and rename AccumulatorExpressionResultScope to ValueExpressionResultScope - Introduce RegisterList to represent consecutive register allocations, and use this for operands to call bytecodes. By avoiding the free-list handling, this gives another couple of percent on CodeLoad. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2369873002 Cr-Commit-Position: refs/heads/master@{#39905}
2016-09-30 09:02:59 +00:00
frame size: 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
parameter count: 1
[Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:01:28 +00:00
bytecode array length: 87
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 42 S> */ B(CreateObjectLiteral), U8(0), U8(4), U8(21), R(1),
[interpreter] Add register output to ObjectLiteral Avoids the always generated Star bytecodes after ObjectLiteral. BUG=v4:4820 LOG=n Review-Url: https://codereview.chromium.org/2216023003 Cr-Commit-Position: refs/heads/master@{#38480}
2016-08-09 10:30:03 +00:00
B(Mov), R(1), R(0),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 77 S> */ B(CreateArrayLiteral), U8(1), U8(5), U8(17),
[Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:01:28 +00:00
B(JumpIfUndefined), U8(72),
B(JumpIfNull), U8(70),
[interpreter] Put object in register for ToObject/ForInPrepare This gets rid of the Star bytecodes that were always dispatched to from ToObject. ToObject now outputs to register instead of to the accumulator and ForInPrepare gets the receiver object from an input register. BUG=v8:4820 LOG=n Review-Url: https://codereview.chromium.org/2189463006 Cr-Commit-Position: refs/heads/master@{#38177}
2016-07-29 11:14:55 +00:00
B(ToObject), R(1),
B(ForInPrepare), R(1), R(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
B(Star), R(5),
[turbofan] Remove special JSForInStep and JSForInDone. These JavaScript operators were special hacks to ensure that we always operate on Smis for the magic for-in index variable, but this never really worked in the OSR case, because the OsrValue for the index variable didn't have the proper information (that we have for the JSForInPrepare in the non-OSR case). Now that we have loop induction variable analysis and binary operation hints, we can just use JSLessThan and JSAdd instead with appropriate Smi hints, which handle the OSR case by inserting Smi checks (that are always true). Thanks to OSR deconstruction and loop peeling these Smi checks will be hoisted so they don't hurt the OSR case too much. Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since we have to lower it to JSLessThan to get the loop induction variable goodness. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289613002 Cr-Commit-Position: refs/heads/master@{#38968}
2016-08-29 08:47:12 +00:00
/* 68 S> */ B(ForInContinue), R(5), R(4),
[Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:01:28 +00:00
B(JumpIfFalse), U8(57),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(ForInNext), R(1), R(5), R(2), U8(16),
[Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:01:28 +00:00
B(JumpIfUndefined), U8(43),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(6),
[Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:01:28 +00:00
B(Ldar), R(6),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 67 E> */ B(StaNamedPropertySloppy), R(0), U8(2), U8(14),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 62 E> */ B(StackCheck),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 95 S> */ B(Nop),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 100 E> */ B(LdaNamedProperty), R(0), U8(2), U8(8),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
B(Star), R(6),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
B(LdaSmi), I8(10),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 106 E> */ B(TestEqual), R(6), U8(10),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(JumpIfFalse), U8(4),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
/* 113 S> */ B(Jump), U8(18),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 125 S> */ B(Nop),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 130 E> */ B(LdaNamedProperty), R(0), U8(2), U8(11),
[Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead. The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:01 +00:00
B(Star), R(6),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
B(LdaSmi), I8(20),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 136 E> */ B(TestEqual), R(6), U8(13),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(JumpIfFalse), U8(4),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
/* 143 S> */ B(Jump), U8(9),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(ForInStep), R(5),
B(Star), R(5),
[Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:01:28 +00:00
B(JumpLoop), U8(57), I8(0),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 152 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
FIXED_ARRAY_TYPE,
Do not use new struct type where unnecessary. We can use TUPLE2 or TUPLE3 for structs that do not need special handling by deoptimizer and compiler. This frees up a few instance types, so that adding the next few new structs will not cause ABI compatibility to break. R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2811183005 Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
TUPLE2_TYPE,
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[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: [
]
---
snippet: "
var x = [ 10, 11, 12 ] ;
for (x[0] in [1,2,3]) { return x[3]; }
"
frame size: 9
parameter count: 1
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
bytecode array length: 62
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 30 E> */ B(StackCheck),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 42 S> */ B(CreateArrayLiteral), U8(0), U8(4), U8(17),
[Interpreter] Preserve source positions in peephole optimizer. The original peephole optimizer logic in the BytecodeArrayBuilder did not respect source positions as it was written before there were bytecode source positions. This led to some minor differences to FCG and was problematic when combined with pending bytecode optimizations. This change makes the new peephole optimizer fully respect source positions. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1998203002 Cr-Commit-Position: refs/heads/master@{#36439}
2016-05-23 13:31:53 +00:00
B(Star), R(0),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 72 S> */ B(CreateArrayLiteral), U8(1), U8(5), U8(17),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
B(JumpIfUndefined), U8(49),
B(JumpIfNull), U8(47),
[interpreter] Put object in register for ToObject/ForInPrepare This gets rid of the Star bytecodes that were always dispatched to from ToObject. ToObject now outputs to register instead of to the accumulator and ForInPrepare gets the receiver object from an input register. BUG=v8:4820 LOG=n Review-Url: https://codereview.chromium.org/2189463006 Cr-Commit-Position: refs/heads/master@{#38177}
2016-07-29 11:14:55 +00:00
B(ToObject), R(1),
B(ForInPrepare), R(1), R(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaZero),
B(Star), R(5),
[turbofan] Remove special JSForInStep and JSForInDone. These JavaScript operators were special hacks to ensure that we always operate on Smis for the magic for-in index variable, but this never really worked in the OSR case, because the OsrValue for the index variable didn't have the proper information (that we have for the JSForInPrepare in the non-OSR case). Now that we have loop induction variable analysis and binary operation hints, we can just use JSLessThan and JSAdd instead with appropriate Smi hints, which handle the OSR case by inserting Smi checks (that are always true). Thanks to OSR deconstruction and loop peeling these Smi checks will be hoisted so they don't hurt the OSR case too much. Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since we have to lower it to JSLessThan to get the loop induction variable goodness. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289613002 Cr-Commit-Position: refs/heads/master@{#38968}
2016-08-29 08:47:12 +00:00
/* 65 S> */ B(ForInContinue), R(5), R(4),
[interpreter] Merge {OsrPoll} with {Jump} bytecode. This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:15 +00:00
B(JumpIfFalse), U8(34),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
B(ForInNext), R(1), R(5), R(2), U8(12),
[interpreter] Filter expression positions at source. With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:32:33 +00:00
B(JumpIfUndefined), U8(20),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(6),
[interpreter] Filter expression positions at source. With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:32:33 +00:00
B(LdaZero),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(8),
B(Ldar), R(6),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 64 E> */ B(StaKeyedPropertySloppy), R(0), R(8), U8(10),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 59 E> */ B(StackCheck),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 83 S> */ B(LdaSmi), I8(3),
[runtime] Move profiler ticks from SFI to feedback vector Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888 Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-03 15:26:53 +00:00
/* 91 E> */ B(LdaKeyedProperty), R(0), U8(8),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
/* 98 S> */ B(Return),
B(ForInStep), R(5),
B(Star), R(5),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
B(JumpLoop), U8(34), I8(0),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 98 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
Do not use new struct type where unnecessary. We can use TUPLE2 or TUPLE3 for structs that do not need special handling by deoptimizer and compiler. This frees up a few instance types, so that adding the next few new structs will not cause ABI compatibility to break. R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2811183005 Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
TUPLE2_TYPE,
TUPLE2_TYPE,
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
Reference in New Issue Copy Permalink