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

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

630 lines
19 KiB
Plaintext
Raw Normal View History

Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: no
top level: yes
print callee: yes
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
oneshot opt: yes
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
---
snippet: "
(function() {
l = {};
l.aa = 2;
l.bb = l.aa;
return arguments.callee;
})();
"
frame size: 6
parameter count: 1
bytecode array length: 82
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
/* 29 S> */ B(CreateEmptyObjectLiteral),
/* 31 E> */ B(StaGlobal), U8(0), U8(0),
/* 45 S> */ B(LdaGlobal), U8(0), U8(2),
B(Star), R(1),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaConstant), U8(1),
B(Star), R(3),
B(LdaZero),
B(Star), R(5),
B(Mov), R(1), R(2),
[Runtime] Use Runtime_SetNamedProperty for property stores in one-shot code. - Rename Runtime_SetProperty to Runtime_SetKeyedProperty - Create Runtime_SetNamedProperty and use it for SetNamed property in one-shot code. - Rename Object::StoreFromKeyed enum to StoreOrigin Bug: v8:8072, chromium:876839 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I22132380ca4b6ce1e0a14a38cca849814559cdcf Reviewed-on: https://chromium-review.googlesource.com/1207870 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55790}
2018-09-10 10:49:08 +00:00
/* 50 E> */ B(CallRuntime), U16(Runtime::kSetNamedProperty), R(2), U8(4),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
/* 63 S> */ B(LdaGlobal), U8(0), U8(2),
B(Star), R(1),
/* 70 E> */ B(LdaGlobal), U8(0), U8(2),
B(Star), R(2),
B(LdaConstant), U8(1),
B(Star), R(4),
B(Mov), R(2), R(3),
/* 72 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(4),
B(LdaConstant), U8(2),
B(Star), R(3),
B(LdaZero),
B(Star), R(5),
B(Mov), R(1), R(2),
[Runtime] Use Runtime_SetNamedProperty for property stores in one-shot code. - Rename Runtime_SetProperty to Runtime_SetKeyedProperty - Create Runtime_SetNamedProperty and use it for SetNamed property in one-shot code. - Rename Object::StoreFromKeyed enum to StoreOrigin Bug: v8:8072, chromium:876839 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I22132380ca4b6ce1e0a14a38cca849814559cdcf Reviewed-on: https://chromium-review.googlesource.com/1207870 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55790}
2018-09-10 10:49:08 +00:00
/* 68 E> */ B(CallRuntime), U16(Runtime::kSetNamedProperty), R(2), U8(4),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
/* 84 S> */ B(LdaConstant), U8(3),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 101 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 108 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["l"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["aa"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["bb"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
---
snippet: "
(function() {
l = {};
for (i = 0; i < 5; ++i) {
l.aa = 2;
l.bb = l.aa;
}
return arguments.callee;
})();
"
frame size: 4
parameter count: 1
bytecode array length: 77
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
/* 29 S> */ B(CreateEmptyObjectLiteral),
/* 31 E> */ B(StaGlobal), U8(0), U8(0),
/* 50 S> */ B(LdaZero),
/* 52 E> */ B(StaGlobal), U8(1), U8(2),
/* 59 S> */ B(LdaGlobal), U8(1), U8(4),
B(Star), R(1),
B(LdaSmi), I8(5),
/* 59 E> */ B(TestLessThan), R(1), U8(6),
B(JumpIfFalse), U8(43),
/* 45 E> */ B(StackCheck),
/* 81 S> */ B(LdaGlobal), U8(0), U8(7),
B(Star), R(1),
B(LdaSmi), I8(2),
/* 86 E> */ B(StaNamedProperty), R(1), U8(2), U8(9),
/* 101 S> */ B(LdaGlobal), U8(0), U8(7),
B(Star), R(1),
/* 108 E> */ B(LdaGlobal), U8(0), U8(7),
B(Star), R(2),
/* 110 E> */ B(LdaNamedProperty), R(2), U8(2), U8(11),
/* 106 E> */ B(StaNamedProperty), R(1), U8(3), U8(13),
/* 66 S> */ B(LdaGlobal), U8(1), U8(4),
B(Inc), U8(15),
/* 66 E> */ B(StaGlobal), U8(1), U8(2),
B(JumpLoop), U8(50), I8(0),
/* 132 S> */ B(LdaConstant), U8(4),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 149 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 156 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["l"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["i"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["aa"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["bb"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
---
snippet: "
(function() {
l = {};
c = 4;
while(c > 4) {
l.aa = 2;
l.bb = l.aa;
c--;
}
return arguments.callee;
})();
"
frame size: 4
parameter count: 1
bytecode array length: 78
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
/* 29 S> */ B(CreateEmptyObjectLiteral),
/* 31 E> */ B(StaGlobal), U8(0), U8(0),
/* 45 S> */ B(LdaSmi), I8(4),
/* 47 E> */ B(StaGlobal), U8(1), U8(2),
/* 68 S> */ B(LdaGlobal), U8(1), U8(4),
B(Star), R(1),
B(LdaSmi), I8(4),
/* 68 E> */ B(TestGreaterThan), R(1), U8(6),
B(JumpIfFalse), U8(43),
/* 60 E> */ B(StackCheck),
/* 85 S> */ B(LdaGlobal), U8(0), U8(7),
B(Star), R(1),
B(LdaSmi), I8(2),
/* 90 E> */ B(StaNamedProperty), R(1), U8(2), U8(9),
/* 105 S> */ B(LdaGlobal), U8(0), U8(7),
B(Star), R(1),
/* 112 E> */ B(LdaGlobal), U8(0), U8(7),
B(Star), R(2),
/* 114 E> */ B(LdaNamedProperty), R(2), U8(2), U8(11),
/* 110 E> */ B(StaNamedProperty), R(1), U8(3), U8(13),
/* 128 S> */ B(LdaGlobal), U8(1), U8(4),
B(Dec), U8(15),
/* 129 E> */ B(StaGlobal), U8(1), U8(2),
B(JumpLoop), U8(50), I8(0),
/* 151 S> */ B(LdaConstant), U8(4),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 168 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 175 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["l"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["c"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["aa"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["bb"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
---
snippet: "
(function() {
l = {};
c = 4;
do {
l.aa = 2;
l.bb = l.aa;
c--;
} while(c > 4)
return arguments.callee;
})();
"
frame size: 4
parameter count: 1
bytecode array length: 78
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
/* 29 S> */ B(CreateEmptyObjectLiteral),
/* 31 E> */ B(StaGlobal), U8(0), U8(0),
/* 45 S> */ B(LdaSmi), I8(4),
/* 47 E> */ B(StaGlobal), U8(1), U8(2),
/* 60 E> */ B(StackCheck),
/* 75 S> */ B(LdaGlobal), U8(0), U8(4),
B(Star), R(1),
B(LdaSmi), I8(2),
/* 80 E> */ B(StaNamedProperty), R(1), U8(2), U8(6),
/* 95 S> */ B(LdaGlobal), U8(0), U8(4),
B(Star), R(1),
/* 102 E> */ B(LdaGlobal), U8(0), U8(4),
B(Star), R(2),
/* 104 E> */ B(LdaNamedProperty), R(2), U8(2), U8(8),
/* 100 E> */ B(StaNamedProperty), R(1), U8(3), U8(10),
/* 118 S> */ B(LdaGlobal), U8(1), U8(12),
B(Dec), U8(14),
/* 119 E> */ B(StaGlobal), U8(1), U8(2),
/* 141 S> */ B(LdaGlobal), U8(1), U8(12),
B(Star), R(1),
B(LdaSmi), I8(4),
/* 141 E> */ B(TestGreaterThan), R(1), U8(15),
B(JumpIfFalse), U8(5),
B(JumpLoop), U8(50), I8(0),
/* 154 S> */ B(LdaConstant), U8(4),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 171 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 178 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["l"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["c"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["aa"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["bb"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
---
snippet: "
(function() {
l = {
'aa': 3.3,
'bb': 4.4
};
if (l.aa < 3) {
l.aa = 3;
} else {
l.aa = l.bb;
}
return arguments.callee;
})();
"
frame size: 6
parameter count: 1
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
bytecode array length: 121
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
/* 29 S> */ B(LdaConstant), U8(0),
B(Star), R(2),
B(LdaSmi), I8(41),
B(Star), R(3),
B(CallRuntime), U16(Runtime::kCreateObjectLiteralWithoutAllocationSite), R(2), U8(2),
/* 31 E> */ B(StaGlobal), U8(1), U8(0),
/* 95 S> */ B(LdaGlobal), U8(1), U8(2),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
B(Star), R(1),
B(LdaConstant), U8(2),
B(Star), R(3),
B(Mov), R(1), R(2),
/* 101 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
B(Star), R(1),
B(LdaSmi), I8(3),
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
/* 104 E> */ B(TestLessThan), R(1), U8(4),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
B(JumpIfFalse), U8(28),
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
/* 121 S> */ B(LdaGlobal), U8(1), U8(2),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
B(Star), R(1),
B(LdaSmi), I8(3),
B(Star), R(4),
B(LdaConstant), U8(2),
B(Star), R(3),
B(LdaZero),
B(Star), R(5),
B(Mov), R(1), R(2),
[Runtime] Use Runtime_SetNamedProperty for property stores in one-shot code. - Rename Runtime_SetProperty to Runtime_SetKeyedProperty - Create Runtime_SetNamedProperty and use it for SetNamed property in one-shot code. - Rename Object::StoreFromKeyed enum to StoreOrigin Bug: v8:8072, chromium:876839 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I22132380ca4b6ce1e0a14a38cca849814559cdcf Reviewed-on: https://chromium-review.googlesource.com/1207870 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55790}
2018-09-10 10:49:08 +00:00
/* 126 E> */ B(CallRuntime), U16(Runtime::kSetNamedProperty), R(2), U8(4),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
B(Jump), U8(40),
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
/* 158 S> */ B(LdaGlobal), U8(1), U8(2),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
B(Star), R(1),
[interpreter][runtime] Avoid AllocationSites for oneshot code No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 12:41:06 +00:00
/* 165 E> */ B(LdaGlobal), U8(1), U8(2),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
B(Star), R(2),
B(LdaConstant), U8(3),
B(Star), R(4),
B(Mov), R(2), R(3),
/* 167 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(4),
B(LdaConstant), U8(2),
B(Star), R(3),
B(LdaZero),
B(Star), R(5),
B(Mov), R(1), R(2),
[Runtime] Use Runtime_SetNamedProperty for property stores in one-shot code. - Rename Runtime_SetProperty to Runtime_SetKeyedProperty - Create Runtime_SetNamedProperty and use it for SetNamed property in one-shot code. - Rename Object::StoreFromKeyed enum to StoreOrigin Bug: v8:8072, chromium:876839 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I22132380ca4b6ce1e0a14a38cca849814559cdcf Reviewed-on: https://chromium-review.googlesource.com/1207870 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55790}
2018-09-10 10:49:08 +00:00
/* 163 E> */ B(CallRuntime), U16(Runtime::kSetNamedProperty), R(2), U8(4),
Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code" This is a reland of 690bda84eb023c7afa63c51131c474771fbf7bda Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-07 13:14:23 +00:00
/* 189 S> */ B(LdaConstant), U8(4),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 206 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 213 S> */ B(Return),
]
constant pool: [
OBJECT_BOILERPLATE_DESCRIPTION_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["l"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["aa"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["bb"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
---
snippet: "
(function() {
a = [0, [1, 1,2,], 3];
return arguments.callee;
})();
"
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
frame size: 5
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
parameter count: 1
bytecode array length: 32
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
/* 29 S> */ B(LdaConstant), U8(0),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Star), R(3),
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
B(LdaSmi), I8(4),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Star), R(4),
B(CallRuntime), U16(Runtime::kCreateArrayLiteralWithoutAllocationSite), R(3), U8(2),
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
/* 31 E> */ B(StaGlobal), U8(1), U8(0),
/* 60 S> */ B(LdaConstant), U8(2),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 77 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 84 S> */ B(Return),
]
constant pool: [
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
---
snippet: "
(function() {
a = [];
return arguments.callee;
})();
"
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
frame size: 5
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
parameter count: 1
bytecode array length: 32
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 16 E> */ B(StackCheck),
/* 29 S> */ B(LdaConstant), U8(0),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Star), R(3),
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
B(LdaSmi), I8(37),
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
B(Star), R(4),
B(CallRuntime), U16(Runtime::kCreateArrayLiteralWithoutAllocationSite), R(3), U8(2),
[interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code No need to create allocation site for array literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateArrayLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1 Reviewed-on: https://chromium-review.googlesource.com/1167843 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 09:50:54 +00:00
/* 31 E> */ B(StaGlobal), U8(1), U8(0),
/* 45 S> */ B(LdaConstant), U8(2),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 62 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 69 S> */ B(Return),
]
constant pool: [
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
[Interpreter] Create and use CallNoFeedback bytecode for one-shot code We do not have to collect feedback for function calls in one-shot code. This CL avoids allocating CallICslots for each function call by emitting CallNoFeedback bytecodes. We save one CallICSlot (two entries in feedback vector) per function call in One-shot. Bug: v8:8072 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ic2580e5972acd5124c2e71d540985736ce797fe8 Reviewed-on: https://chromium-review.googlesource.com/1178051 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55951}
2018-09-17 08:44:19 +00:00
---
snippet: "
this.f0 = function() {};
this.f1 = function(a) {};
this.f2 = function(a, b) {};
this.f3 = function(a, b, c) {};
this.f4 = function(a, b, c, d) {};
this.f5 = function(a, b, c, d, e) {};
(function() {
this.f0();
this.f1(1);
this.f2(1, 2);
this.f3(1, 2, 3);
this.f4(1, 2, 3, 4);
this.f5(1, 2, 3, 4, 5);
return arguments.callee;
})();
"
frame size: 8
parameter count: 1
bytecode array length: 193
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 237 E> */ B(StackCheck),
/* 250 S> */ B(LdaConstant), U8(0),
B(Star), R(4),
B(Mov), R(this), R(3),
/* 255 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(1),
/* 255 E> */ B(CallNoFeedback), R(1), R(3), U8(1),
/* 269 S> */ B(LdaConstant), U8(1),
B(Star), R(4),
B(Mov), R(this), R(3),
/* 274 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(Mov), R(this), R(2),
/* 274 E> */ B(CallNoFeedback), R(1), R(2), U8(2),
/* 289 S> */ B(LdaConstant), U8(2),
B(Star), R(4),
B(Mov), R(this), R(3),
/* 294 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(Mov), R(this), R(2),
/* 294 E> */ B(CallNoFeedback), R(1), R(2), U8(3),
/* 312 S> */ B(LdaConstant), U8(3),
B(Star), R(4),
B(Mov), R(this), R(3),
/* 317 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaSmi), I8(3),
B(Star), R(5),
B(Mov), R(this), R(2),
/* 317 E> */ B(CallNoFeedback), R(1), R(2), U8(4),
/* 338 S> */ B(LdaConstant), U8(4),
B(Star), R(4),
B(Mov), R(this), R(3),
/* 343 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaSmi), I8(3),
B(Star), R(5),
B(LdaSmi), I8(4),
B(Star), R(6),
B(Mov), R(this), R(2),
/* 343 E> */ B(CallNoFeedback), R(1), R(2), U8(5),
/* 367 S> */ B(LdaConstant), U8(5),
B(Star), R(4),
B(Mov), R(this), R(3),
/* 372 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(3), U8(2),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaSmi), I8(3),
B(Star), R(5),
B(LdaSmi), I8(4),
B(Star), R(6),
B(LdaSmi), I8(5),
B(Star), R(7),
B(Mov), R(this), R(2),
/* 372 E> */ B(CallNoFeedback), R(1), R(2), U8(6),
/* 399 S> */ B(LdaConstant), U8(6),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 416 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 423 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f0"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f1"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f2"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f3"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f4"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f5"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
---
snippet: "
function f0() {}
function f1(a) {}
function f2(a, b) {}
function f3(a, b, c) {}
function f4(a, b, c, d) {}
function f5(a, b, c, d, e) {}
(function() {
f0();
f1(1);
f2(1, 2);
f3(1, 2, 3);
f4(1, 2, 3, 4);
f5(1, 2, 3, 4, 5);
return arguments.callee;
})();
"
frame size: 8
parameter count: 1
bytecode array length: 148
bytecodes: [
B(CreateMappedArguments),
B(Star), R(0),
/* 189 E> */ B(StackCheck),
/* 202 S> */ B(LdaUndefined),
B(Star), R(2),
B(LdaGlobal), U8(0), U8(0),
B(Star), R(1),
/* 202 E> */ B(CallNoFeedback), R(1), R(2), U8(1),
/* 216 S> */ B(LdaUndefined),
B(Star), R(2),
B(LdaGlobal), U8(1), U8(2),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
/* 216 E> */ B(CallNoFeedback), R(1), R(2), U8(2),
/* 231 S> */ B(LdaUndefined),
B(Star), R(2),
B(LdaGlobal), U8(2), U8(4),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
/* 231 E> */ B(CallNoFeedback), R(1), R(2), U8(3),
/* 249 S> */ B(LdaUndefined),
B(Star), R(2),
B(LdaGlobal), U8(3), U8(6),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaSmi), I8(3),
B(Star), R(5),
/* 249 E> */ B(CallNoFeedback), R(1), R(2), U8(4),
/* 270 S> */ B(LdaUndefined),
B(Star), R(2),
B(LdaGlobal), U8(4), U8(8),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaSmi), I8(3),
B(Star), R(5),
B(LdaSmi), I8(4),
B(Star), R(6),
/* 270 E> */ B(CallNoFeedback), R(1), R(2), U8(5),
/* 294 S> */ B(LdaUndefined),
B(Star), R(2),
B(LdaGlobal), U8(5), U8(10),
B(Star), R(1),
B(LdaSmi), I8(1),
B(Star), R(3),
B(LdaSmi), I8(2),
B(Star), R(4),
B(LdaSmi), I8(3),
B(Star), R(5),
B(LdaSmi), I8(4),
B(Star), R(6),
B(LdaSmi), I8(5),
B(Star), R(7),
/* 294 E> */ B(CallNoFeedback), R(1), R(2), U8(6),
/* 321 S> */ B(LdaConstant), U8(6),
B(Star), R(3),
B(Mov), R(0), R(2),
/* 338 E> */ B(InvokeIntrinsic), U8(Runtime::k_GetProperty), R(2), U8(2),
/* 345 S> */ B(Return),
]
constant pool: [
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f0"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f1"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f2"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f3"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f4"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["f5"],
ONE_BYTE_INTERNALIZED_STRING_TYPE ["callee"],
]
handlers: [
]
Reference in New Issue Copy Permalink