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

262 lines
8.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: "
class Person {
constructor(name) { this.name = name; }
speak() { console.log(this.name + ' is speaking.'); }
}
"
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
frame size: 8
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 1
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 67
[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
B(CreateClosure), U8(0), U8(4), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(2),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(3),
[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(34),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
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(Wide), B(LdaSmi), I16(148),
[ignition] Avoid unnecessary ToName calls in VisitClassLiteralProperties R=rmcilroy@chromium.org BUG=v8:5799 Review-Url: https://codereview.chromium.org/2612903002 Cr-Commit-Position: refs/heads/master@{#42098}
2017-01-05 18:25:25 +00:00
B(Star), R(6),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
B(LdaConstant), U8(1),
B(Star), R(5),
[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(CreateClosure), U8(2), U8(5), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +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(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(7),
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
B(StaDataPropertyInLiteral), R(3), R(5), U8(1), U8(6),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(2), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(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
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
B(LdaUndefined),
/* 149 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
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["speak"],
SHARED_FUNCTION_INFO_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: "
class person {
constructor(name) { this.name = name; }
speak() { console.log(this.name + ' is speaking.'); }
}
"
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
frame size: 8
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 1
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 67
[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
B(CreateClosure), U8(0), U8(4), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(2),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(3),
[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(34),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
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(Wide), B(LdaSmi), I16(148),
[ignition] Avoid unnecessary ToName calls in VisitClassLiteralProperties R=rmcilroy@chromium.org BUG=v8:5799 Review-Url: https://codereview.chromium.org/2612903002 Cr-Commit-Position: refs/heads/master@{#42098}
2017-01-05 18:25:25 +00:00
B(Star), R(6),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
B(LdaConstant), U8(1),
B(Star), R(5),
[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(CreateClosure), U8(2), U8(5), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +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(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(7),
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
B(StaDataPropertyInLiteral), R(3), R(5), U8(1), U8(6),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(2), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(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
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
B(LdaUndefined),
/* 149 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
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["speak"],
SHARED_FUNCTION_INFO_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 n0 = 'a';
var n1 = 'b';
class N {
[n0]() { return n0; }
static [n1]() { return n1; }
}
"
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
frame size: 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
parameter count: 1
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 106
[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 CreateFunctionContext bytecode Add a new bytecode to create a function context. The handler inlines FastNewFunctionContextStub. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2187523002 Cr-Commit-Position: refs/heads/master@{#38301}
2016-08-03 14:41:47 +00:00
B(CreateFunctionContext), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(PushContext), 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
/* 30 E> */ B(StackCheck),
/* 43 S> */ B(LdaConstant), U8(0),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 43 E> */ B(StaCurrentContextSlot), U8(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
/* 57 S> */ B(LdaConstant), U8(1),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 57 E> */ B(StaCurrentContextSlot), U8(5),
[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(CreateClosure), U8(2), U8(4), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(3),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(4),
[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(62),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +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(Wide), B(LdaSmi), I16(128),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(7),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
B(Star), R(4),
Reland of Thread maybe-assigned through the bytecodes. (patchset #1 id:1 of https://codereview.chromium.org/2680923003/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ ) > > Reason for revert: > needed for properly reverting https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 > > Original issue's description: > > Thread maybe-assigned through the bytecodes. > > > > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot > > bytecodes, which are emitted when reading from never-assigned context slot. > > > > There is a subtlety here: the slot are not immutable, the meaning is > > actually undefined-or-hole-or-immutable. > > > > Review-Url: https://codereview.chromium.org/2655733003 > > Cr-Commit-Position: refs/heads/master@{#43000} > > Committed: https://chromium.googlesource.com/v8/v8/+/17c2dd388697da626224c371c8181d20d2016d82 > > TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Review-Url: https://codereview.chromium.org/2680923003 > Cr-Commit-Position: refs/heads/master@{#43011} > Committed: https://chromium.googlesource.com/v8/v8/+/ece4e54a31ac76ee9c450270d65270562db716e1 TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2679953003 Cr-Commit-Position: refs/heads/master@{#43012}
2017-02-07 20:42:03 +00:00
B(LdaImmutableCurrentContextSlot), U8(4),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
/* 75 E> */ B(ToName), 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
B(CreateClosure), U8(3), U8(5), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +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(LdaSmi), I8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(8),
B(Ldar), R(7),
[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(StaDataPropertyInLiteral), R(4), R(6), U8(3), U8(7),
Reland of Thread maybe-assigned through the bytecodes. (patchset #1 id:1 of https://codereview.chromium.org/2680923003/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ ) > > Reason for revert: > needed for properly reverting https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 > > Original issue's description: > > Thread maybe-assigned through the bytecodes. > > > > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot > > bytecodes, which are emitted when reading from never-assigned context slot. > > > > There is a subtlety here: the slot are not immutable, the meaning is > > actually undefined-or-hole-or-immutable. > > > > Review-Url: https://codereview.chromium.org/2655733003 > > Cr-Commit-Position: refs/heads/master@{#43000} > > Committed: https://chromium.googlesource.com/v8/v8/+/17c2dd388697da626224c371c8181d20d2016d82 > > TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Review-Url: https://codereview.chromium.org/2680923003 > Cr-Commit-Position: refs/heads/master@{#43011} > Committed: https://chromium.googlesource.com/v8/v8/+/ece4e54a31ac76ee9c450270d65270562db716e1 TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2679953003 Cr-Commit-Position: refs/heads/master@{#43012}
2017-02-07 20:42:03 +00:00
B(LdaImmutableCurrentContextSlot), U8(5),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
/* 106 E> */ B(ToName), R(6),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaConstant), U8(4),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(TestEqualStrictNoFeedback), R(6),
B(Mov), R(3), R(5),
[Interpreter] Move ToBoolean elision in BytecodeGenerator. Move the ToBoolean elision in the BytecodeGenerator instead of the peephole optimizer. Adds a TypeHint mechanism to the ExpressionResult to enable passing of type hints through the ast visitor. BUG=v8:6194 Change-Id: Ic55506ba11b213f7459250004d3f18cab04ee9b3 Reviewed-on: https://chromium-review.googlesource.com/467208 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44415}
2017-04-05 15:40:27 +00:00
B(JumpIfFalse), U8(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(CallRuntime), U16(Runtime::kThrowStaticPrototypeError), R(0), U8(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
B(CreateClosure), U8(5), U8(6), U8(2),
B(StaDataPropertyInLiteral), R(5), R(6), U8(3), U8(9),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(CallRuntime), U16(Runtime::kInstallClassNameAccessorWithCheck), R(3), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(3), U8(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(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
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
B(LdaUndefined),
/* 129 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 ["a"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["b"],
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["prototype"],
[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
SHARED_FUNCTION_INFO_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 count = 0;
class C { constructor() { count++; }}
return new C();
"
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
frame size: 8
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 1
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +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 CreateFunctionContext bytecode Add a new bytecode to create a function context. The handler inlines FastNewFunctionContextStub. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2187523002 Cr-Commit-Position: refs/heads/master@{#38301}
2016-08-03 14:41:47 +00:00
B(CreateFunctionContext), U8(1),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(PushContext), 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
/* 30 E> */ B(StackCheck),
/* 46 S> */ B(LdaZero),
[ignition] Add bytecodes for loads/stores in the current context The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:10:32 +00:00
/* 46 E> */ B(StaCurrentContextSlot), U8(4),
[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(CreateClosure), U8(0), U8(4), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(3),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(4),
[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(49),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +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(86),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(7),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
B(Star), R(4),
B(CallRuntime), U16(Runtime::kInstallClassNameAccessor), R(3), U8(1),
B(CallRuntime), U16(Runtime::kToFastProperties), R(3), U8(1),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(Star), R(0),
[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(1),
[ignition] Eliminate hole checks where statically possible for loads and stores Move hole check logic from full-codegen into scope analysis, and store the "needs hole check" bit on VariableProxy. This makes it easy to re-use in any backend: it will be trivial to extend the use of this logic in, e.g., full-codegen variable stores. While changing the signatures of the variable loading/storing methods in Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these are not part of AST visiting. BUG=v8:5460 Review-Url: https://chromiumcodereview.appspot.com/2411873004 Cr-Commit-Position: refs/heads/master@{#40479}
2016-10-20 17:31:36 +00:00
/* 87 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
/* 94 E> */ B(Construct), R(1), R(0), U8(0), U8(5),
[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
/* 103 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
SHARED_FUNCTION_INFO_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: [
]
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
---
snippet: "
(class {})
class E { static name () {}}
"
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
frame size: 8
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
parameter count: 1
Skip hole initialization of lexical variables when possible This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
2017-05-08 18:55:54 +00:00
bytecode array length: 92
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
bytecodes: [
/* 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
/* 34 S> */ B(CreateClosure), U8(0), U8(4), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(2),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(3),
[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(35),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(5),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(LdaSmi), I8(43),
B(Star), R(6),
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(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
B(CreateClosure), U8(1), U8(5), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(2),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaTheHole),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(3),
[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(45),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(5),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(LdaSmi), I8(73),
B(Star), R(6),
B(Mov), R(2), R(4),
B(CallRuntime), U16(Runtime::kDefineClass), R(3), U8(4),
B(Star), R(3),
[ignition] Only initialize [[HomeObject]] for class constructors if needed This moves the initialization of [[HomeObject]] for constructors from the %DefineClass runtime function into the bytecode generator, and makes it conditional (resolving an old TODO). As part of this refactor, avoid a load of "prototype" by returning the class prototype from %DefineClass. This is one of many steps in moving more of class definition into bytecode. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2610683003 Cr-Commit-Position: refs/heads/master@{#42072}
2017-01-04 19:15:26 +00:00
B(LdaConstant), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(5),
[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(CreateClosure), U8(3), U8(6), U8(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +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(2),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(7),
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
B(StaDataPropertyInLiteral), R(4), R(5), U8(1), U8(7),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(CallRuntime), U16(Runtime::kToFastProperties), R(2), U8(1),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(Star), R(0),
[es6] don't use do-expressions to desugar ES6 classes Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
2017-05-04 17:00:44 +00:00
B(Star), R(1),
Install the 'name' property in classes at runtime This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant. BUG=v8:4199 Review-Url: https://codereview.chromium.org/2423053002 Cr-Commit-Position: refs/heads/master@{#41546}
2016-12-07 10:34:15 +00:00
B(LdaUndefined),
/* 74 S> */ B(Return),
]
constant pool: [
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name"],
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
Reference in New Issue Copy Permalink