v8/test/cctest/interpreter/bytecode_expectations/BreakableBlocks.golden

184 lines
4.2 KiB
Plaintext
Raw Normal View History

#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: yes
---
snippet: "
var x = 0;
label: {
x = x + 1;
break label;
x = x + 1;
}
return x;
"
frame size: 1
parameter count: 1
bytecode array length: 16
bytecodes: [
/* 30 E> */ B(StackCheck),
/* 42 S> */ B(LdaZero),
B(Star), R(0),
/* 56 S> */ B(LdaSmi), U8(1),
/* 62 E> */ B(Add), R(0), U8(2),
B(Star), R(0),
/* 69 S> */ B(Jump), U8(2),
/* 97 S> */ B(Ldar), R(0),
/* 107 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
var sum = 0;
outer: {
for (var x = 0; x < 10; ++x) {
for (var y = 0; y < 3; ++y) {
++sum;
if (x + y == 12) { break outer; }
}
}
}
return sum;
"
frame size: 4
parameter count: 1
bytecode array length: 69
bytecodes: [
/* 30 E> */ B(StackCheck),
/* 44 S> */ B(LdaZero),
B(Star), R(0),
/* 71 S> */ B(LdaZero),
B(Star), R(1),
/* 76 S> */ B(LdaSmi), U8(10),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@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(TestLessThan), R(1), U8(2),
B(JumpIfFalse), U8(54),
/* 58 E> */ B(StackCheck),
/* 106 S> */ B(LdaZero),
B(Star), R(2),
/* 111 S> */ B(LdaSmi), U8(3),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
/* 111 E> */ B(TestLessThan), R(2), U8(4),
B(JumpIfFalse), U8(34),
/* 93 E> */ B(StackCheck),
/* 129 S> */ B(Ldar), R(0),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
B(Inc), U8(6),
B(Star), R(0),
/* 142 S> */ B(Ldar), R(2),
/* 148 E> */ B(Add), R(1), U8(7),
B(Star), R(3),
B(LdaSmi), U8(12),
/* 152 E> */ B(TestEqual), R(3), U8(8),
B(JumpIfFalse), U8(4),
/* 161 S> */ B(Jump), U8(20),
/* 118 S> */ B(Ldar), R(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
B(Inc), U8(5),
B(Star), R(2),
B(JumpLoop), U8(-36), U8(1),
/* 84 S> */ B(Ldar), R(1),
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
B(Inc), U8(3),
B(Star), R(1),
B(JumpLoop), U8(-56), U8(0),
/* 188 S> */ B(Ldar), R(0),
/* 200 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
outer: {
let y = 10;
function f() { return y; }
break outer;
}
"
frame size: 3
parameter count: 1
bytecode array length: 30
bytecodes: [
/* 30 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(2),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(CreateClosure), U8(1), U8(2),
B(Star), R(0),
/* 53 S> */ B(LdaSmi), U8(10),
/* 53 E> */ B(StaCurrentContextSlot), U8(4),
B(Mov), R(0), R(1),
B(Ldar), R(0),
/* 88 S> */ B(Jump), U8(2),
B(PopContext), R(2),
B(LdaUndefined),
/* 103 S> */ B(Return),
]
constant pool: [
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
---
snippet: "
let x = 1;
outer: {
inner: {
let y = 2;
function f() { return x + y; }
if (y) break outer;
y = 3;
}
}
x = 4;
"
frame size: 4
parameter count: 1
bytecode array length: 53
bytecodes: [
B(CreateFunctionContext), U8(1),
B(PushContext), R(2),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
/* 30 E> */ B(StackCheck),
/* 42 S> */ B(LdaSmi), U8(1),
/* 42 E> */ B(StaCurrentContextSlot), U8(4),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(3),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(CreateClosure), U8(1), U8(2),
B(Star), R(0),
/* 76 S> */ B(LdaSmi), U8(2),
/* 76 E> */ B(StaCurrentContextSlot), U8(4),
B(Mov), R(0), R(1),
/* 118 S> */ B(LdaCurrentContextSlot), U8(4),
B(JumpIfToBooleanFalse), U8(6),
/* 125 S> */ B(PopContext), R(3),
B(Jump), U8(8),
/* 142 S> */ B(LdaSmi), U8(3),
/* 144 E> */ B(StaCurrentContextSlot), U8(4),
B(PopContext), R(3),
/* 155 S> */ B(LdaSmi), U8(4),
/* 157 E> */ B(StaCurrentContextSlot), U8(4),
B(LdaUndefined),
/* 162 S> */ B(Return),
]
constant pool: [
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]