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

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

526 lines
10 KiB
Plaintext
Raw Normal View History

#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
test function name: f
---
snippet: "
function f() {
if (0) {
return 1;
} else {
return -1;
}
};
f();
"
frame size: 0
parameter count: 1
bytecode array length: 4
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 55 S> */ B(LdaSmi), I8(-1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 65 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f() {
if ('lucky') {
return 1;
} else {
return -1;
}
};
f();
"
frame size: 0
parameter count: 1
bytecode array length: 4
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 36 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 45 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f() {
if (false) {
return 1;
} else {
return -1;
}
};
f();
"
frame size: 0
parameter count: 1
bytecode array length: 4
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 59 S> */ B(LdaSmi), I8(-1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 69 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f() {
if (false) {
return 1;
}
};
f();
"
frame size: 0
parameter count: 1
bytecode array length: 3
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 17 S> */ B(LdaUndefined),
/* 48 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f() {
var a = 1;
if (a) {
a += 1;
} else {
return 2;
}
};
f();
"
Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" This relands commit d3e9aade0ff24e100621ab451e83f703439ace9e. The original CL was reverted speculatively but didn't cause the buildbot failure. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6194 Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8 Reviewed-on: https://chromium-review.googlesource.com/472746 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44511}
2017-04-10 09:30:51 +00:00
frame size: 1
parameter count: 1
Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" This relands commit d3e9aade0ff24e100621ab451e83f703439ace9e. The original CL was reverted speculatively but didn't cause the buildbot failure. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6194 Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8 Reviewed-on: https://chromium-review.googlesource.com/472746 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44511}
2017-04-10 09:30:51 +00:00
bytecode array length: 21
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 25 S> */ B(LdaSmi), I8(1),
B(Star), R(0),
Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" This relands commit d3e9aade0ff24e100621ab451e83f703439ace9e. The original CL was reverted speculatively but didn't cause the buildbot failure. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6194 Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8 Reviewed-on: https://chromium-review.googlesource.com/472746 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44511}
2017-04-10 09:30:51 +00:00
/* 30 S> */ B(JumpIfToBooleanFalse), U8(11),
/* 43 S> */ B(Ldar), R(0),
B(AddSmi), I8(1), U8(0),
B(Star), R(0),
B(Jump), U8(5),
/* 66 S> */ B(LdaSmi), I8(2),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 75 S> */ B(Return),
B(LdaUndefined),
/* 80 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f(a) {
if (a <= 0) {
return 200;
} else {
return -200;
}
};
f(99);
"
frame size: 0
parameter count: 2
bytecode array length: 19
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 18 S> */ B(LdaZero),
/* 24 E> */ B(TestLessThanOrEqual), R(arg0), U8(0),
B(JumpIfFalse), U8(7),
/* 36 S> */ B(Wide), B(LdaSmi), I16(200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 47 S> */ B(Return),
/* 63 S> */ B(Wide), B(LdaSmi), I16(-200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 75 S> */ B(Return),
B(LdaUndefined),
/* 80 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f(a, b) { if (a in b) { return 200; } }f('prop', { prop: 'yes'});
"
frame size: 0
parameter count: 3
bytecode array length: 14
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 19 S> */ B(Ldar), R(arg1),
/* 25 E> */ B(TestIn), R(arg0),
B(JumpIfFalse), U8(7),
/* 33 S> */ B(Wide), B(LdaSmi), I16(200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 44 S> */ B(Return),
B(LdaUndefined),
/* 47 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f(z) { var a = 0; var b = 0; if (a === 0.01) {
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
return 200; } else { return -200; } } f(0.001);
"
frame size: 2
parameter count: 2
bytecode array length: 29
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 24 S> */ B(LdaZero),
B(Star), R(0),
/* 35 S> */ B(LdaZero),
B(Star), R(1),
/* 38 S> */ B(LdaConstant), U8(0),
/* 44 E> */ B(TestEqualStrict), R(0), U8(0),
B(JumpIfFalse), U8(10),
/* 58 S> */ B(Mov), R(0), R(1),
/* 1081 S> */ B(Wide), B(LdaSmi), I16(200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 1092 S> */ B(Return),
/* 1102 S> */ B(Wide), B(LdaSmi), I16(-200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 1114 S> */ B(Return),
B(LdaUndefined),
/* 1117 S> */ B(Return),
]
constant pool: [
HEAP_NUMBER_TYPE [0.01],
]
handlers: [
]
---
snippet: "
function f() {
var a = 0; var b = 0;
if (a) {
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
b = a; a = b;
return 200; } else { return -200; }
};
f();
"
frame size: 2
parameter count: 1
bytecode array length: 26
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 25 S> */ B(LdaZero),
B(Star), R(0),
/* 36 S> */ B(LdaZero),
B(Star), R(1),
/* 41 S> */ B(Ldar), R(0),
B(JumpIfToBooleanFalse), U8(10),
/* 52 S> */ B(Mov), R(0), R(1),
/* 1076 S> */ B(Wide), B(LdaSmi), I16(200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 1087 S> */ B(Return),
/* 1097 S> */ B(Wide), B(LdaSmi), I16(-200),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 1109 S> */ B(Return),
B(LdaUndefined),
/* 1112 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f(a, b) {
if (a == b) { return 1; }
if (a === b) { return 1; }
if (a < b) { return 1; }
if (a > b) { return 1; }
if (a <= b) { return 1; }
if (a >= b) { return 1; }
if (a in b) { return 1; }
if (a instanceof b) { return 1; }
return 0;
}
f(1, 1);
"
frame size: 0
parameter count: 3
[turbofan] Introduce InstanceOfIC to collect rhs feedback. This adds a new InstanceOfIC where the TestInstanceOf bytecode collects constant feedback about the right-hand side of instanceof operators, including both JSFunction and JSBoundFunction instances. TurboFan then uses the feedback to optimize instanceof in places where the right-hand side is not a known constant (known to TurboFan). This addresses the odd performance cliff that we see with instanceof in functions with multiple closures. It was discovered as one of the main bottlenecks on the uglify-es test in the web-tooling-benchmark. The uglify-es test (run in separation) is ~18% faster with this change. On the micro-benchmark in the tracking bug we go from instanceofSingleClosure_Const: 69 ms. instanceofSingleClosure_Class: 246 ms. instanceofMultiClosure: 246 ms. instanceofParameter: 246 ms. to instanceofSingleClosure_Const: 70 ms. instanceofSingleClosure_Class: 75 ms. instanceofMultiClosure: 76 ms. instanceofParameter: 73 ms. boosting performance by roughly 3.6x and thus effectively removing the performance cliff around instanceof. Bug: v8:6936, v8:6971 Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e Reviewed-on: https://chromium-review.googlesource.com/730686 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 09:18:57 +00:00
bytecode array length: 82
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 21 S> */ B(Ldar), R(arg1),
/* 27 E> */ B(TestEqual), R(arg0), U8(0),
B(JumpIfFalse), U8(5),
/* 35 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 44 S> */ B(Return),
/* 49 S> */ B(Ldar), R(arg1),
/* 55 E> */ B(TestEqualStrict), R(arg0), U8(1),
B(JumpIfFalse), U8(5),
/* 64 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 73 S> */ B(Return),
/* 78 S> */ B(Ldar), R(arg1),
/* 84 E> */ B(TestLessThan), R(arg0), U8(2),
B(JumpIfFalse), U8(5),
/* 91 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 100 S> */ B(Return),
/* 105 S> */ B(Ldar), R(arg1),
/* 111 E> */ B(TestGreaterThan), R(arg0), U8(3),
B(JumpIfFalse), U8(5),
/* 118 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 127 S> */ B(Return),
/* 132 S> */ B(Ldar), R(arg1),
/* 138 E> */ B(TestLessThanOrEqual), R(arg0), U8(4),
B(JumpIfFalse), U8(5),
/* 146 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 155 S> */ B(Return),
/* 160 S> */ B(Ldar), R(arg1),
/* 166 E> */ B(TestGreaterThanOrEqual), R(arg0), U8(5),
B(JumpIfFalse), U8(5),
/* 174 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 183 S> */ B(Return),
/* 188 S> */ B(Ldar), R(arg1),
/* 194 E> */ B(TestIn), R(arg0),
B(JumpIfFalse), U8(5),
/* 202 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 211 S> */ B(Return),
/* 216 S> */ B(Ldar), R(arg1),
[turbofan] Introduce InstanceOfIC to collect rhs feedback. This adds a new InstanceOfIC where the TestInstanceOf bytecode collects constant feedback about the right-hand side of instanceof operators, including both JSFunction and JSBoundFunction instances. TurboFan then uses the feedback to optimize instanceof in places where the right-hand side is not a known constant (known to TurboFan). This addresses the odd performance cliff that we see with instanceof in functions with multiple closures. It was discovered as one of the main bottlenecks on the uglify-es test in the web-tooling-benchmark. The uglify-es test (run in separation) is ~18% faster with this change. On the micro-benchmark in the tracking bug we go from instanceofSingleClosure_Const: 69 ms. instanceofSingleClosure_Class: 246 ms. instanceofMultiClosure: 246 ms. instanceofParameter: 246 ms. to instanceofSingleClosure_Const: 70 ms. instanceofSingleClosure_Class: 75 ms. instanceofMultiClosure: 76 ms. instanceofParameter: 73 ms. boosting performance by roughly 3.6x and thus effectively removing the performance cliff around instanceof. Bug: v8:6936, v8:6971 Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e Reviewed-on: https://chromium-review.googlesource.com/730686 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 09:18:57 +00:00
/* 222 E> */ B(TestInstanceOf), R(arg0), U8(6),
B(JumpIfFalse), U8(5),
/* 238 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 247 S> */ B(Return),
/* 252 S> */ B(LdaZero),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 261 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f() {
var a = 0;
if (a) {
return 20;
} else {
return -20;
}
};
f();
"
frame size: 1
parameter count: 1
bytecode array length: 14
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 25 S> */ B(LdaZero),
B(Star), R(0),
/* 30 S> */ B(JumpIfToBooleanFalse), U8(5),
/* 43 S> */ B(LdaSmi), I8(20),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 53 S> */ B(Return),
/* 69 S> */ B(LdaSmi), I8(-20),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 80 S> */ B(Return),
B(LdaUndefined),
/* 85 S> */ B(Return),
]
constant pool: [
]
handlers: [
]
---
snippet: "
function f(a, b) {
if (a == b || a < 0) {
return 1;
} else if (a > 0 && b > 0) {
return 0;
} else {
return -1;
}
};
f(-1, 1);
"
frame size: 0
parameter count: 3
bytecode array length: 36
bytecodes: [
/* 10 E> */ B(StackCheck),
/* 21 S> */ B(Ldar), R(arg1),
/* 27 E> */ B(TestEqual), R(arg0), U8(0),
B(JumpIfTrue), U8(8),
B(LdaZero),
/* 37 E> */ B(TestLessThan), R(arg0), U8(1),
B(JumpIfFalse), U8(5),
/* 48 S> */ B(LdaSmi), I8(1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 57 S> */ B(Return),
/* 67 S> */ B(LdaZero),
/* 73 E> */ B(TestGreaterThan), R(arg0), U8(2),
B(JumpIfFalse), U8(10),
B(LdaZero),
/* 82 E> */ B(TestGreaterThan), R(arg1), U8(3),
B(JumpIfFalse), U8(4),
/* 93 S> */ B(LdaZero),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 102 S> */ B(Return),
/* 118 S> */ B(LdaSmi), I8(-1),
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
/* 128 S> */ B(Return),
B(LdaUndefined),
/* 133 S> */ B(Return),
]
constant pool: [
]
handlers: [
]