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

348 lines
11 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
[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
bytecode array length: 5
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
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
/* 21 E> */ B(StackCheck),
Revert "[runtime] Move profiler ticks from SFI to feedback vector" This reverts commit a2fcdc7cc8b286941ca054bf62c8a51166e39379. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [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} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
2017-07-17 11:22:25 +00:00
/* 26 S> */ B(LdaGlobal), U8(0), U8(3),
[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
[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
bytecode array length: 5
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
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
/* 27 E> */ B(StackCheck),
Revert "[runtime] Move profiler ticks from SFI to feedback vector" This reverts commit a2fcdc7cc8b286941ca054bf62c8a51166e39379. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [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} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
2017-07-17 11:22:25 +00:00
/* 32 S> */ B(LdaGlobal), U8(0), U8(3),
[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
[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
bytecode array length: 5
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
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
/* 17 E> */ B(StackCheck),
Revert "[runtime] Move profiler ticks from SFI to feedback vector" This reverts commit a2fcdc7cc8b286941ca054bf62c8a51166e39379. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [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} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
2017-07-17 11:22:25 +00:00
/* 22 S> */ B(LdaGlobal), U8(0), U8(3),
[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;
function f(b) {
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
b.name;
return a;
}
f({name: 1});
"
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
frame size: 0
[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
[ignition] removed nop bytecode Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them. There are at least two changes which this CL produce: - we don't provide break position when we load local variable (still provide when load variable from global), - we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement. More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing Bug: v8:6425 Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda Reviewed-on: https://chromium-review.googlesource.com/543161 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46742}
2017-07-17 19:02:35 +00:00
bytecode array length: 524
[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
/* 17 E> */ B(StackCheck),
[ignition] removed nop bytecode Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them. There are at least two changes which this CL produce: - we don't provide break position when we load local variable (still provide when load variable from global), - we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement. More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing Bug: v8:6425 Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda Reviewed-on: https://chromium-review.googlesource.com/543161 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46742}
2017-07-17 19:02:35 +00:00
/* 27 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(3),
/* 37 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(5),
/* 47 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(7),
/* 57 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(9),
/* 67 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(11),
/* 77 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(13),
/* 87 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(15),
/* 97 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(17),
/* 107 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(19),
/* 117 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(21),
/* 127 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(23),
/* 137 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(25),
/* 147 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(27),
/* 157 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(29),
/* 167 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(31),
/* 177 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(33),
/* 187 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(35),
/* 197 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(37),
/* 207 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(39),
/* 217 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(41),
/* 227 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(43),
/* 237 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(45),
/* 247 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(47),
/* 257 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(49),
/* 267 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(51),
/* 277 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(53),
/* 287 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(55),
/* 297 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(57),
/* 307 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(59),
/* 317 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(61),
/* 327 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(63),
/* 337 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(65),
/* 347 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(67),
/* 357 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(69),
/* 367 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(71),
/* 377 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(73),
/* 387 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(75),
/* 397 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(77),
/* 407 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(79),
/* 417 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(81),
/* 427 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(83),
/* 437 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(85),
/* 447 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(87),
/* 457 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(89),
/* 467 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(91),
/* 477 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(93),
/* 487 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(95),
/* 497 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(97),
/* 507 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(99),
/* 517 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(101),
/* 527 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(103),
/* 537 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(105),
/* 547 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(107),
/* 557 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(109),
/* 567 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(111),
/* 577 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(113),
/* 587 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(115),
/* 597 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(117),
/* 607 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(119),
/* 617 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(121),
/* 627 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(123),
/* 637 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(125),
/* 647 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(127),
/* 657 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(129),
/* 667 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(131),
/* 677 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(133),
/* 687 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(135),
/* 697 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(137),
/* 707 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(139),
/* 717 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(141),
/* 727 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(143),
/* 737 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(145),
/* 747 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(147),
/* 757 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(149),
/* 767 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(151),
/* 777 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(153),
/* 787 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(155),
/* 797 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(157),
/* 807 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(159),
/* 817 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(161),
/* 827 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(163),
/* 837 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(165),
/* 847 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(167),
/* 857 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(169),
/* 867 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(171),
/* 877 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(173),
/* 887 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(175),
/* 897 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(177),
/* 907 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(179),
/* 917 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(181),
/* 927 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(183),
/* 937 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(185),
/* 947 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(187),
/* 957 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(189),
/* 967 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(191),
/* 977 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(193),
/* 987 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(195),
/* 997 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(197),
/* 1007 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(199),
/* 1017 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(201),
/* 1027 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(203),
/* 1037 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(205),
/* 1047 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(207),
/* 1057 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(209),
/* 1067 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(211),
/* 1077 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(213),
/* 1087 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(215),
/* 1097 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(217),
/* 1107 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(219),
/* 1117 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(221),
/* 1127 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(223),
/* 1137 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(225),
/* 1147 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(227),
/* 1157 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(229),
/* 1167 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(231),
/* 1177 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(233),
/* 1187 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(235),
/* 1197 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(237),
/* 1207 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(239),
/* 1217 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(241),
/* 1227 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(243),
/* 1237 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(245),
/* 1247 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(247),
/* 1257 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(249),
/* 1267 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(251),
/* 1277 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(253),
/* 1287 S> */ B(LdaNamedProperty), R(arg0), U8(0), U8(255),
/* 1297 S> */ B(Wide), B(LdaNamedProperty), R16(arg0), U16(0), U16(257),
Revert "[runtime] Move profiler ticks from SFI to feedback vector" This reverts commit a2fcdc7cc8b286941ca054bf62c8a51166e39379. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [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} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
2017-07-17 11:22:25 +00:00
/* 1305 S> */ B(Wide), B(LdaGlobal), U16(1), U16(259),
[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
/* 1314 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 ["name"],
[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