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

915 lines
27 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() { a = 2; }
f();
"
frame size: 0
parameter count: 1
bytecode array length: 8
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),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 26 S> */ B(LdaSmi), I8(2),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 28 E> */ B(StaGlobalSloppy), U8(0), U8(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 33 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
handlers: [
]
---
snippet: "
var a = \"test\"; function f(b) { a = b; }
f(\"global\");
"
frame size: 0
parameter count: 2
bytecode array length: 8
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
/* 26 E> */ B(StackCheck),
/* 32 S> */ B(Ldar), R(arg0),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 34 E> */ B(StaGlobalSloppy), U8(0), U8(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 39 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[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: "
'use strict'; var a = 1;
function f() { a = 2; }
f();
"
frame size: 0
parameter count: 1
bytecode array length: 8
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
/* 35 E> */ B(StackCheck),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 40 S> */ B(LdaSmi), I8(2),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 42 E> */ B(StaGlobalStrict), U8(0), U8(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 47 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[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() { a = 2; }
f();
"
frame size: 0
parameter count: 1
bytecode array length: 8
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] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 22 S> */ B(LdaSmi), I8(2),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 24 E> */ B(StaGlobalSloppy), U8(0), U8(2),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 29 S> */ B(Return),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
]
constant pool: [
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
[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;
a = 2;
}
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
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
bytecode array length: 655
[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),
[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
/* 25 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 26 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(2),
[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
/* 35 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 36 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(4),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 45 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 46 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(6),
[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
/* 55 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 56 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(8),
[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
/* 65 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 66 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(10),
[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
/* 75 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 76 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(12),
[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
/* 85 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 86 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(14),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 95 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 96 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(16),
[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
/* 105 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 106 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(18),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 115 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 116 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(20),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 125 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 126 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(22),
[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
/* 135 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 136 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(24),
[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
/* 145 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 146 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(26),
[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
/* 155 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 156 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(28),
[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
/* 165 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 166 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(30),
[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
/* 175 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 176 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(32),
[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
/* 185 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 186 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(34),
[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
/* 195 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 196 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(36),
[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
/* 205 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 206 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(38),
[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
/* 215 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 216 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(40),
[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
/* 225 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 226 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(42),
[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
/* 235 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 236 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(44),
[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
/* 245 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 246 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(46),
[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
/* 255 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 256 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(48),
[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
/* 265 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 266 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(50),
[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
/* 275 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 276 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(52),
[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
/* 285 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 286 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(54),
[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
/* 295 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 296 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(56),
[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
/* 305 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 306 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(58),
[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
/* 315 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 316 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(60),
[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
/* 325 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 326 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(62),
[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
/* 335 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 336 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(64),
[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
/* 345 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 346 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(66),
[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
/* 355 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 356 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(68),
[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
/* 365 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 366 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(70),
[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
/* 375 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 376 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(72),
[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
/* 385 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 386 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(74),
[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
/* 395 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 396 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(76),
[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
/* 405 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 406 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(78),
[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
/* 415 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 416 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(80),
[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
/* 425 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 426 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(82),
[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
/* 435 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 436 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(84),
[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
/* 445 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 446 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(86),
[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
/* 455 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 456 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(88),
[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
/* 465 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 466 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(90),
[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
/* 475 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 476 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(92),
[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
/* 485 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 486 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(94),
[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
/* 495 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 496 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(96),
[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
/* 505 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 506 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(98),
[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
/* 515 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 516 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(100),
[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
/* 525 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 526 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(102),
[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
/* 535 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 536 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(104),
[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
/* 545 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 546 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(106),
[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
/* 555 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 556 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(108),
[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
/* 565 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 566 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(110),
[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
/* 575 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 576 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(112),
[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
/* 585 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 586 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(114),
[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
/* 595 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 596 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(116),
[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
/* 605 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 606 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(118),
[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
/* 615 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 616 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(120),
[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
/* 625 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 626 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(122),
[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
/* 635 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 636 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(124),
[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
/* 645 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 646 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(126),
[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
/* 655 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 656 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(128),
[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
/* 665 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 666 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(130),
[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
/* 675 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 676 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(132),
[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
/* 685 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 686 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(134),
[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
/* 695 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 696 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(136),
[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
/* 705 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 706 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(138),
[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
/* 715 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 716 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(140),
[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
/* 725 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 726 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(142),
[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
/* 735 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 736 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(144),
[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
/* 745 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 746 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(146),
[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
/* 755 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 756 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(148),
[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
/* 765 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 766 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(150),
[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
/* 775 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 776 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(152),
[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
/* 785 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 786 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(154),
[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
/* 795 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 796 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(156),
[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
/* 805 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 806 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(158),
[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
/* 815 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 816 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(160),
[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
/* 825 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 826 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(162),
[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
/* 835 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 836 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(164),
[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
/* 845 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 846 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(166),
[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
/* 855 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 856 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(168),
[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
/* 865 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 866 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(170),
[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
/* 875 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 876 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(172),
[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
/* 885 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 886 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(174),
[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
/* 895 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 896 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(176),
[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
/* 905 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 906 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(178),
[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
/* 915 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 916 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(180),
[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
/* 925 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 926 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(182),
[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
/* 935 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 936 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(184),
[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
/* 945 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 946 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(186),
[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
/* 955 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 956 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(188),
[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
/* 965 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 966 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(190),
[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
/* 975 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 976 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(192),
[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
/* 985 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 986 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(194),
[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
/* 995 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 996 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(196),
[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
/* 1005 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1006 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(198),
[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
/* 1015 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1016 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(200),
[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
/* 1025 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1026 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(202),
[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
/* 1035 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1036 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(204),
[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
/* 1045 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1046 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(206),
[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
/* 1055 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1056 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(208),
[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
/* 1065 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1066 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(210),
[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
/* 1075 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1076 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(212),
[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
/* 1085 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1086 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(214),
[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
/* 1095 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1096 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(216),
[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
/* 1105 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1106 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(218),
[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
/* 1115 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1116 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(220),
[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
/* 1125 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1126 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(222),
[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
/* 1135 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1136 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(224),
[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
/* 1145 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1146 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(226),
[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
/* 1155 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1156 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(228),
[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
/* 1165 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1166 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(230),
[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
/* 1175 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1176 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(232),
[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
/* 1185 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1186 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(234),
[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
/* 1195 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1196 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(236),
[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
/* 1205 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1206 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(238),
[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
/* 1215 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1216 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(240),
[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
/* 1225 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1226 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(242),
[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
/* 1235 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1236 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(244),
[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
/* 1245 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1246 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(246),
[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
/* 1255 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1256 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(248),
[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
/* 1265 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1266 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(250),
[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
/* 1275 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1276 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(252),
[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
/* 1285 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1286 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(254),
[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
/* 1295 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1296 E> */ B(Wide), B(LdaNamedProperty), R16(arg0), U16(0), U16(256),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 1305 S> */ B(LdaSmi), I8(2),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1307 E> */ B(Wide), B(StaGlobalSloppy), U16(1), U16(258),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 1312 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"],
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) {
'use strict';
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;
a = 2;
}
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
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
bytecode array length: 655
[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),
[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
/* 41 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 42 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(2),
[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
/* 51 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 52 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(4),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 61 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 62 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(6),
[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
/* 71 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 72 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(8),
[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
/* 81 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 82 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(10),
[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
/* 91 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 92 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(12),
[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
/* 101 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 102 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(14),
[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
/* 111 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 112 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(16),
[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
/* 121 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 122 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(18),
[interpreter] Bytecode register optimizer. Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:57:35 +00:00
/* 131 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 132 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(20),
[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
/* 141 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 142 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(22),
[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
/* 151 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 152 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(24),
[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
/* 161 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 162 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(26),
[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
/* 171 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 172 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(28),
[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
/* 181 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 182 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(30),
[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
/* 191 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 192 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(32),
[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
/* 201 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 202 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(34),
[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
/* 211 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 212 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(36),
[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
/* 221 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 222 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(38),
[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
/* 231 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 232 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(40),
[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
/* 241 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 242 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(42),
[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
/* 251 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 252 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(44),
[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
/* 261 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 262 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(46),
[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
/* 271 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 272 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(48),
[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
/* 281 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 282 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(50),
[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
/* 291 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 292 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(52),
[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
/* 301 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 302 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(54),
[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
/* 311 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 312 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(56),
[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
/* 321 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 322 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(58),
[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
/* 331 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 332 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(60),
[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
/* 341 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 342 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(62),
[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
/* 351 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 352 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(64),
[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
/* 361 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 362 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(66),
[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
/* 371 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 372 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(68),
[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
/* 381 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 382 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(70),
[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
/* 391 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 392 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(72),
[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
/* 401 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 402 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(74),
[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
/* 411 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 412 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(76),
[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
/* 421 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 422 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(78),
[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
/* 431 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 432 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(80),
[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
/* 441 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 442 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(82),
[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
/* 451 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 452 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(84),
[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
/* 461 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 462 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(86),
[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
/* 471 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 472 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(88),
[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
/* 481 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 482 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(90),
[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
/* 491 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 492 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(92),
[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
/* 501 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 502 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(94),
[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
/* 511 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 512 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(96),
[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
/* 521 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 522 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(98),
[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
/* 531 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 532 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(100),
[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
/* 541 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 542 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(102),
[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
/* 551 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 552 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(104),
[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
/* 561 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 562 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(106),
[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
/* 571 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 572 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(108),
[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
/* 581 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 582 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(110),
[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
/* 591 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 592 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(112),
[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
/* 601 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 602 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(114),
[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
/* 611 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 612 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(116),
[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
/* 621 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 622 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(118),
[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
/* 631 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 632 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(120),
[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
/* 641 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 642 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(122),
[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
/* 651 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 652 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(124),
[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
/* 661 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 662 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(126),
[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
/* 671 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 672 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(128),
[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
/* 681 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 682 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(130),
[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
/* 691 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 692 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(132),
[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
/* 701 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 702 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(134),
[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
/* 711 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 712 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(136),
[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
/* 721 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 722 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(138),
[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
/* 731 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 732 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(140),
[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
/* 741 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 742 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(142),
[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
/* 751 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 752 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(144),
[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
/* 761 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 762 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(146),
[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
/* 771 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 772 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(148),
[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
/* 781 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 782 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(150),
[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
/* 791 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 792 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(152),
[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
/* 801 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 802 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(154),
[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
/* 811 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 812 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(156),
[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
/* 821 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 822 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(158),
[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
/* 831 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 832 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(160),
[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
/* 841 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 842 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(162),
[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
/* 851 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 852 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(164),
[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
/* 861 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 862 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(166),
[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
/* 871 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 872 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(168),
[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
/* 881 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 882 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(170),
[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
/* 891 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 892 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(172),
[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
/* 901 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 902 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(174),
[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
/* 911 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 912 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(176),
[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
/* 921 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 922 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(178),
[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
/* 931 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 932 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(180),
[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
/* 941 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 942 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(182),
[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
/* 951 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 952 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(184),
[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
/* 961 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 962 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(186),
[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
/* 971 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 972 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(188),
[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
/* 981 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 982 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(190),
[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
/* 991 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 992 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(192),
[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
/* 1001 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1002 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(194),
[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
/* 1011 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1012 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(196),
[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
/* 1021 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1022 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(198),
[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
/* 1031 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1032 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(200),
[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
/* 1041 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1042 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(202),
[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
/* 1051 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1052 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(204),
[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
/* 1061 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1062 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(206),
[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
/* 1071 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1072 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(208),
[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
/* 1081 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1082 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(210),
[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
/* 1091 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1092 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(212),
[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
/* 1101 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1102 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(214),
[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
/* 1111 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1112 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(216),
[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
/* 1121 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1122 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(218),
[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
/* 1131 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1132 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(220),
[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
/* 1141 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1142 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(222),
[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
/* 1151 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1152 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(224),
[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
/* 1161 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1162 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(226),
[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
/* 1171 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1172 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(228),
[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
/* 1181 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1182 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(230),
[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
/* 1191 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1192 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(232),
[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
/* 1201 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1202 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(234),
[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
/* 1211 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1212 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(236),
[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
/* 1221 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1222 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(238),
[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
/* 1231 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1232 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(240),
[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
/* 1241 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1242 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(242),
[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
/* 1251 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1252 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(244),
[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
/* 1261 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1262 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(246),
[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
/* 1271 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1272 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(248),
[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
/* 1281 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1282 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(250),
[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
/* 1291 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1292 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(252),
[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
/* 1301 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1302 E> */ B(LdaNamedProperty), R(arg0), U8(0), U8(254),
[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
/* 1311 S> */ B(Nop),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1312 E> */ B(Wide), B(LdaNamedProperty), R16(arg0), U16(0), U16(256),
[ignition] Expect 'I' for signed bytecode operands Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
/* 1321 S> */ B(LdaSmi), I8(2),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 1323 E> */ B(Wide), B(StaGlobalStrict), U16(1), U16(258),
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
B(LdaUndefined),
/* 1328 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"],
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