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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

474 lines
17 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: no
test function name: f
---
snippet: "
var a = 1;
function f() { return a; }
f()
"
frame size: 0
parameter count: 1
[interpreter] Make FunctionEntry StackCheck bytecodes implicit FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
2020-02-10 16:09:27 +00:00
bytecode array length: 4
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 26 S> */ B(LdaGlobal), U8(0), U8(0),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 35 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: [
[ic] Pass name to LoadGlobalIC again. The reasons are: 1) The names dictionaries in the feedback metadata seems to consume a lot of memory and the idea didn't payoff. 2) The absence of a name parameter blocks data handlers support in LoadGlobalIC. This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/). BUG=chromium:576312, v8:5561 Review-Url: https://codereview.chromium.org/2510653002 Cr-Commit-Position: refs/heads/master@{#41046}
2016-11-16 18:17:22 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
---
snippet: "
function t() { }
function f() { return t; }
f()
"
frame size: 0
parameter count: 1
[interpreter] Make FunctionEntry StackCheck bytecodes implicit FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
2020-02-10 16:09:27 +00:00
bytecode array length: 4
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 32 S> */ B(LdaGlobal), U8(0), U8(0),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 41 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: [
[ic] Pass name to LoadGlobalIC again. The reasons are: 1) The names dictionaries in the feedback metadata seems to consume a lot of memory and the idea didn't payoff. 2) The absence of a name parameter blocks data handlers support in LoadGlobalIC. This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/). BUG=chromium:576312, v8:5561 Review-Url: https://codereview.chromium.org/2510653002 Cr-Commit-Position: refs/heads/master@{#41046}
2016-11-16 18:17:22 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["t"],
[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: "
a = 1;
function f() { return a; }
f()
"
frame size: 0
parameter count: 1
[interpreter] Make FunctionEntry StackCheck bytecodes implicit FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
2020-02-10 16:09:27 +00:00
bytecode array length: 4
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
bytecodes: [
[objects] Make feedback vector a first-class object Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 12:45:00 +00:00
/* 22 S> */ B(LdaGlobal), U8(0), U8(0),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 31 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: [
[ic] Pass name to LoadGlobalIC again. The reasons are: 1) The names dictionaries in the feedback metadata seems to consume a lot of memory and the idea didn't payoff. 2) The absence of a name parameter blocks data handlers support in LoadGlobalIC. This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/). BUG=chromium:576312, v8:5561 Review-Url: https://codereview.chromium.org/2510653002 Cr-Commit-Position: refs/heads/master@{#41046}
2016-11-16 18:17:22 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
---
snippet: "
a = 1;
[Interpreter] Share feedback slots for load / store named properties Shares the feedback slot when loading / storing named properties when the name of the property and the variable corresponding to the object are the same. This reduces the memory usage on most real world benchmarks. There is a slight (~1%) increase in the overall time spent in V8 on a couple of these pages. There is also no overall performance regression on peak-performance benchmarks like Octane, ARES. More detailed results are in this doc[1] [1]: https://docs.google.com/document/d/1rPNjXU-WOlyNQovuQS28Zf2PHCENR97Bi76gV9mHHOc/edit?usp=sharing BUG: v8:7530 Change-Id: I7dd98c2d26f4e6c94690ca7d9a8a4a8281b3142d Reviewed-on: https://chromium-review.googlesource.com/966302 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53145}
2018-05-11 08:52:00 +00:00
function f(c) {
var b = {};
b.name512;
b.name513;
b.name514;
b.name515;
b.name516;
b.name517;
b.name518;
b.name519;
b.name520;
b.name521;
b.name522;
b.name523;
b.name524;
b.name525;
b.name526;
b.name527;
b.name528;
b.name529;
b.name530;
b.name531;
b.name532;
b.name533;
b.name534;
b.name535;
b.name536;
b.name537;
b.name538;
b.name539;
b.name540;
b.name541;
b.name542;
b.name543;
b.name544;
b.name545;
b.name546;
b.name547;
b.name548;
b.name549;
b.name550;
b.name551;
b.name552;
b.name553;
b.name554;
b.name555;
b.name556;
b.name557;
b.name558;
b.name559;
b.name560;
b.name561;
b.name562;
b.name563;
b.name564;
b.name565;
b.name566;
b.name567;
b.name568;
b.name569;
b.name570;
b.name571;
b.name572;
b.name573;
b.name574;
b.name575;
b.name576;
b.name577;
b.name578;
b.name579;
b.name580;
b.name581;
b.name582;
b.name583;
b.name584;
b.name585;
b.name586;
b.name587;
b.name588;
b.name589;
b.name590;
b.name591;
b.name592;
b.name593;
b.name594;
b.name595;
b.name596;
b.name597;
b.name598;
b.name599;
b.name600;
b.name601;
b.name602;
b.name603;
b.name604;
b.name605;
b.name606;
b.name607;
b.name608;
b.name609;
b.name610;
b.name611;
b.name612;
b.name613;
b.name614;
b.name615;
b.name616;
b.name617;
b.name618;
b.name619;
b.name620;
b.name621;
b.name622;
b.name623;
b.name624;
b.name625;
b.name626;
b.name627;
b.name628;
b.name629;
b.name630;
b.name631;
b.name632;
b.name633;
b.name634;
b.name635;
b.name636;
b.name637;
b.name638;
b.name639;
[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
return a;
}
f({name: 1});
"
[Interpreter] Share feedback slots for load / store named properties Shares the feedback slot when loading / storing named properties when the name of the property and the variable corresponding to the object are the same. This reduces the memory usage on most real world benchmarks. There is a slight (~1%) increase in the overall time spent in V8 on a couple of these pages. There is also no overall performance regression on peak-performance benchmarks like Octane, ARES. More detailed results are in this doc[1] [1]: https://docs.google.com/document/d/1rPNjXU-WOlyNQovuQS28Zf2PHCENR97Bi76gV9mHHOc/edit?usp=sharing BUG: v8:7530 Change-Id: I7dd98c2d26f4e6c94690ca7d9a8a4a8281b3142d Reviewed-on: https://chromium-review.googlesource.com/966302 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53145}
2018-05-11 08:52:00 +00:00
frame size: 1
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
parameter count: 2
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 521
[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] Share feedback slots for load / store named properties Shares the feedback slot when loading / storing named properties when the name of the property and the variable corresponding to the object are the same. This reduces the memory usage on most real world benchmarks. There is a slight (~1%) increase in the overall time spent in V8 on a couple of these pages. There is also no overall performance regression on peak-performance benchmarks like Octane, ARES. More detailed results are in this doc[1] [1]: https://docs.google.com/document/d/1rPNjXU-WOlyNQovuQS28Zf2PHCENR97Bi76gV9mHHOc/edit?usp=sharing BUG: v8:7530 Change-Id: I7dd98c2d26f4e6c94690ca7d9a8a4a8281b3142d Reviewed-on: https://chromium-review.googlesource.com/966302 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53145}
2018-05-11 08:52:00 +00:00
/* 33 S> */ B(CreateEmptyObjectLiteral),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star0),
[Interpreter] Share feedback slots for load / store named properties Shares the feedback slot when loading / storing named properties when the name of the property and the variable corresponding to the object are the same. This reduces the memory usage on most real world benchmarks. There is a slight (~1%) increase in the overall time spent in V8 on a couple of these pages. There is also no overall performance regression on peak-performance benchmarks like Octane, ARES. More detailed results are in this doc[1] [1]: https://docs.google.com/document/d/1rPNjXU-WOlyNQovuQS28Zf2PHCENR97Bi76gV9mHHOc/edit?usp=sharing BUG: v8:7530 Change-Id: I7dd98c2d26f4e6c94690ca7d9a8a4a8281b3142d Reviewed-on: https://chromium-review.googlesource.com/966302 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53145}
2018-05-11 08:52:00 +00:00
/* 41 S> */ B(LdaNamedProperty), R(0), U8(0), U8(0),
/* 54 S> */ B(LdaNamedProperty), R(0), U8(1), U8(2),
/* 67 S> */ B(LdaNamedProperty), R(0), U8(2), U8(4),
/* 80 S> */ B(LdaNamedProperty), R(0), U8(3), U8(6),
/* 93 S> */ B(LdaNamedProperty), R(0), U8(4), U8(8),
/* 106 S> */ B(LdaNamedProperty), R(0), U8(5), U8(10),
/* 119 S> */ B(LdaNamedProperty), R(0), U8(6), U8(12),
/* 132 S> */ B(LdaNamedProperty), R(0), U8(7), U8(14),
/* 145 S> */ B(LdaNamedProperty), R(0), U8(8), U8(16),
/* 158 S> */ B(LdaNamedProperty), R(0), U8(9), U8(18),
/* 171 S> */ B(LdaNamedProperty), R(0), U8(10), U8(20),
/* 184 S> */ B(LdaNamedProperty), R(0), U8(11), U8(22),
/* 197 S> */ B(LdaNamedProperty), R(0), U8(12), U8(24),
/* 210 S> */ B(LdaNamedProperty), R(0), U8(13), U8(26),
/* 223 S> */ B(LdaNamedProperty), R(0), U8(14), U8(28),
/* 236 S> */ B(LdaNamedProperty), R(0), U8(15), U8(30),
/* 249 S> */ B(LdaNamedProperty), R(0), U8(16), U8(32),
/* 262 S> */ B(LdaNamedProperty), R(0), U8(17), U8(34),
/* 275 S> */ B(LdaNamedProperty), R(0), U8(18), U8(36),
/* 288 S> */ B(LdaNamedProperty), R(0), U8(19), U8(38),
/* 301 S> */ B(LdaNamedProperty), R(0), U8(20), U8(40),
/* 314 S> */ B(LdaNamedProperty), R(0), U8(21), U8(42),
/* 327 S> */ B(LdaNamedProperty), R(0), U8(22), U8(44),
/* 340 S> */ B(LdaNamedProperty), R(0), U8(23), U8(46),
/* 353 S> */ B(LdaNamedProperty), R(0), U8(24), U8(48),
/* 366 S> */ B(LdaNamedProperty), R(0), U8(25), U8(50),
/* 379 S> */ B(LdaNamedProperty), R(0), U8(26), U8(52),
/* 392 S> */ B(LdaNamedProperty), R(0), U8(27), U8(54),
/* 405 S> */ B(LdaNamedProperty), R(0), U8(28), U8(56),
/* 418 S> */ B(LdaNamedProperty), R(0), U8(29), U8(58),
/* 431 S> */ B(LdaNamedProperty), R(0), U8(30), U8(60),
/* 444 S> */ B(LdaNamedProperty), R(0), U8(31), U8(62),
/* 457 S> */ B(LdaNamedProperty), R(0), U8(32), U8(64),
/* 470 S> */ B(LdaNamedProperty), R(0), U8(33), U8(66),
/* 483 S> */ B(LdaNamedProperty), R(0), U8(34), U8(68),
/* 496 S> */ B(LdaNamedProperty), R(0), U8(35), U8(70),
/* 509 S> */ B(LdaNamedProperty), R(0), U8(36), U8(72),
/* 522 S> */ B(LdaNamedProperty), R(0), U8(37), U8(74),
/* 535 S> */ B(LdaNamedProperty), R(0), U8(38), U8(76),
/* 548 S> */ B(LdaNamedProperty), R(0), U8(39), U8(78),
/* 561 S> */ B(LdaNamedProperty), R(0), U8(40), U8(80),
/* 574 S> */ B(LdaNamedProperty), R(0), U8(41), U8(82),
/* 587 S> */ B(LdaNamedProperty), R(0), U8(42), U8(84),
/* 600 S> */ B(LdaNamedProperty), R(0), U8(43), U8(86),
/* 613 S> */ B(LdaNamedProperty), R(0), U8(44), U8(88),
/* 626 S> */ B(LdaNamedProperty), R(0), U8(45), U8(90),
/* 639 S> */ B(LdaNamedProperty), R(0), U8(46), U8(92),
/* 652 S> */ B(LdaNamedProperty), R(0), U8(47), U8(94),
/* 665 S> */ B(LdaNamedProperty), R(0), U8(48), U8(96),
/* 678 S> */ B(LdaNamedProperty), R(0), U8(49), U8(98),
/* 691 S> */ B(LdaNamedProperty), R(0), U8(50), U8(100),
/* 704 S> */ B(LdaNamedProperty), R(0), U8(51), U8(102),
/* 717 S> */ B(LdaNamedProperty), R(0), U8(52), U8(104),
/* 730 S> */ B(LdaNamedProperty), R(0), U8(53), U8(106),
/* 743 S> */ B(LdaNamedProperty), R(0), U8(54), U8(108),
/* 756 S> */ B(LdaNamedProperty), R(0), U8(55), U8(110),
/* 769 S> */ B(LdaNamedProperty), R(0), U8(56), U8(112),
/* 782 S> */ B(LdaNamedProperty), R(0), U8(57), U8(114),
/* 795 S> */ B(LdaNamedProperty), R(0), U8(58), U8(116),
/* 808 S> */ B(LdaNamedProperty), R(0), U8(59), U8(118),
/* 821 S> */ B(LdaNamedProperty), R(0), U8(60), U8(120),
/* 834 S> */ B(LdaNamedProperty), R(0), U8(61), U8(122),
/* 847 S> */ B(LdaNamedProperty), R(0), U8(62), U8(124),
/* 860 S> */ B(LdaNamedProperty), R(0), U8(63), U8(126),
/* 873 S> */ B(LdaNamedProperty), R(0), U8(64), U8(128),
/* 886 S> */ B(LdaNamedProperty), R(0), U8(65), U8(130),
/* 899 S> */ B(LdaNamedProperty), R(0), U8(66), U8(132),
/* 912 S> */ B(LdaNamedProperty), R(0), U8(67), U8(134),
/* 925 S> */ B(LdaNamedProperty), R(0), U8(68), U8(136),
/* 938 S> */ B(LdaNamedProperty), R(0), U8(69), U8(138),
/* 951 S> */ B(LdaNamedProperty), R(0), U8(70), U8(140),
/* 964 S> */ B(LdaNamedProperty), R(0), U8(71), U8(142),
/* 977 S> */ B(LdaNamedProperty), R(0), U8(72), U8(144),
/* 990 S> */ B(LdaNamedProperty), R(0), U8(73), U8(146),
/* 1003 S> */ B(LdaNamedProperty), R(0), U8(74), U8(148),
/* 1016 S> */ B(LdaNamedProperty), R(0), U8(75), U8(150),
/* 1029 S> */ B(LdaNamedProperty), R(0), U8(76), U8(152),
/* 1042 S> */ B(LdaNamedProperty), R(0), U8(77), U8(154),
/* 1055 S> */ B(LdaNamedProperty), R(0), U8(78), U8(156),
/* 1068 S> */ B(LdaNamedProperty), R(0), U8(79), U8(158),
/* 1081 S> */ B(LdaNamedProperty), R(0), U8(80), U8(160),
/* 1094 S> */ B(LdaNamedProperty), R(0), U8(81), U8(162),
/* 1107 S> */ B(LdaNamedProperty), R(0), U8(82), U8(164),
/* 1120 S> */ B(LdaNamedProperty), R(0), U8(83), U8(166),
/* 1133 S> */ B(LdaNamedProperty), R(0), U8(84), U8(168),
/* 1146 S> */ B(LdaNamedProperty), R(0), U8(85), U8(170),
/* 1159 S> */ B(LdaNamedProperty), R(0), U8(86), U8(172),
/* 1172 S> */ B(LdaNamedProperty), R(0), U8(87), U8(174),
/* 1185 S> */ B(LdaNamedProperty), R(0), U8(88), U8(176),
/* 1198 S> */ B(LdaNamedProperty), R(0), U8(89), U8(178),
/* 1211 S> */ B(LdaNamedProperty), R(0), U8(90), U8(180),
/* 1224 S> */ B(LdaNamedProperty), R(0), U8(91), U8(182),
/* 1237 S> */ B(LdaNamedProperty), R(0), U8(92), U8(184),
/* 1250 S> */ B(LdaNamedProperty), R(0), U8(93), U8(186),
/* 1263 S> */ B(LdaNamedProperty), R(0), U8(94), U8(188),
/* 1276 S> */ B(LdaNamedProperty), R(0), U8(95), U8(190),
/* 1289 S> */ B(LdaNamedProperty), R(0), U8(96), U8(192),
/* 1302 S> */ B(LdaNamedProperty), R(0), U8(97), U8(194),
/* 1315 S> */ B(LdaNamedProperty), R(0), U8(98), U8(196),
/* 1328 S> */ B(LdaNamedProperty), R(0), U8(99), U8(198),
/* 1341 S> */ B(LdaNamedProperty), R(0), U8(100), U8(200),
/* 1354 S> */ B(LdaNamedProperty), R(0), U8(101), U8(202),
/* 1367 S> */ B(LdaNamedProperty), R(0), U8(102), U8(204),
/* 1380 S> */ B(LdaNamedProperty), R(0), U8(103), U8(206),
/* 1393 S> */ B(LdaNamedProperty), R(0), U8(104), U8(208),
/* 1406 S> */ B(LdaNamedProperty), R(0), U8(105), U8(210),
/* 1419 S> */ B(LdaNamedProperty), R(0), U8(106), U8(212),
/* 1432 S> */ B(LdaNamedProperty), R(0), U8(107), U8(214),
/* 1445 S> */ B(LdaNamedProperty), R(0), U8(108), U8(216),
/* 1458 S> */ B(LdaNamedProperty), R(0), U8(109), U8(218),
/* 1471 S> */ B(LdaNamedProperty), R(0), U8(110), U8(220),
/* 1484 S> */ B(LdaNamedProperty), R(0), U8(111), U8(222),
/* 1497 S> */ B(LdaNamedProperty), R(0), U8(112), U8(224),
/* 1510 S> */ B(LdaNamedProperty), R(0), U8(113), U8(226),
/* 1523 S> */ B(LdaNamedProperty), R(0), U8(114), U8(228),
/* 1536 S> */ B(LdaNamedProperty), R(0), U8(115), U8(230),
/* 1549 S> */ B(LdaNamedProperty), R(0), U8(116), U8(232),
/* 1562 S> */ B(LdaNamedProperty), R(0), U8(117), U8(234),
/* 1575 S> */ B(LdaNamedProperty), R(0), U8(118), U8(236),
/* 1588 S> */ B(LdaNamedProperty), R(0), U8(119), U8(238),
/* 1601 S> */ B(LdaNamedProperty), R(0), U8(120), U8(240),
/* 1614 S> */ B(LdaNamedProperty), R(0), U8(121), U8(242),
/* 1627 S> */ B(LdaNamedProperty), R(0), U8(122), U8(244),
/* 1640 S> */ B(LdaNamedProperty), R(0), U8(123), U8(246),
/* 1653 S> */ B(LdaNamedProperty), R(0), U8(124), U8(248),
/* 1666 S> */ B(LdaNamedProperty), R(0), U8(125), U8(250),
/* 1679 S> */ B(LdaNamedProperty), R(0), U8(126), U8(252),
/* 1692 S> */ B(LdaNamedProperty), R(0), U8(127), U8(254),
/* 1703 S> */ B(Wide), B(LdaGlobal), U16(128), U16(256),
/* 1712 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] Share feedback slots for load / store named properties Shares the feedback slot when loading / storing named properties when the name of the property and the variable corresponding to the object are the same. This reduces the memory usage on most real world benchmarks. There is a slight (~1%) increase in the overall time spent in V8 on a couple of these pages. There is also no overall performance regression on peak-performance benchmarks like Octane, ARES. More detailed results are in this doc[1] [1]: https://docs.google.com/document/d/1rPNjXU-WOlyNQovuQS28Zf2PHCENR97Bi76gV9mHHOc/edit?usp=sharing BUG: v8:7530 Change-Id: I7dd98c2d26f4e6c94690ca7d9a8a4a8281b3142d Reviewed-on: https://chromium-review.googlesource.com/966302 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53145}
2018-05-11 08:52:00 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name512"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name513"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name514"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name515"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name516"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name517"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name518"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name519"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name520"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name521"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name522"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name523"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name524"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name525"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name526"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name527"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name528"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name529"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name530"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name531"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name532"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name533"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name534"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name535"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name536"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name537"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name538"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name539"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name540"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name541"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name542"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name543"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name544"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name545"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name546"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name547"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name548"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name549"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name550"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name551"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name552"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name553"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name554"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name555"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name556"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name557"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name558"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name559"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name560"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name561"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name562"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name563"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name564"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name565"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name566"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name567"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name568"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name569"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name570"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name571"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name572"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name573"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name574"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name575"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name576"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name577"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name578"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name579"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name580"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name581"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name582"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name583"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name584"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name585"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name586"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name587"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name588"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name589"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name590"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name591"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name592"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name593"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name594"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name595"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name596"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name597"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name598"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name599"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name600"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name601"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name602"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name603"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name604"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name605"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name606"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name607"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name608"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name609"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name610"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name611"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name612"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name613"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name614"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name615"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name616"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name617"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name618"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name619"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name620"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name621"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name622"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name623"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name624"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name625"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name626"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name627"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name628"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name629"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name630"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name631"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name632"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name633"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name634"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name635"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name636"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name637"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name638"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["name639"],
[ic] Pass name to LoadGlobalIC again. The reasons are: 1) The names dictionaries in the feedback metadata seems to consume a lot of memory and the idea didn't payoff. 2) The absence of a name parameter blocks data handlers support in LoadGlobalIC. This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/). BUG=chromium:576312, v8:5561 Review-Url: https://codereview.chromium.org/2510653002 Cr-Commit-Position: refs/heads/master@{#41046}
2016-11-16 18:17:22 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
Reference in New Issue Copy Permalink