AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
fb1687cbd9
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.

409 lines
12 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),
/* 50 E> */ B(CallRuntime), U16(Runtime::kSetProperty), R(2), U8(4),
/* 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),
/* 68 E> */ B(CallRuntime), U16(Runtime::kSetProperty), R(2), U8(4),
/* 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),
/* 126 E> */ B(CallRuntime), U16(Runtime::kSetProperty), R(2), U8(4),
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),
/* 163 E> */ B(CallRuntime), U16(Runtime::kSetProperty), R(2), U8(4),
/* 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;
})();
"
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. 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} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
frame size: 4
[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),
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. 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} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
B(Star), R(1),
[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),
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. 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} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
B(Star), R(2),
B(CallRuntime), U16(Runtime::kCreateArrayLiteralWithoutAllocationSite), R(1), 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;
})();
"
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. 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} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
frame size: 4
[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),
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. 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} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
B(Star), R(1),
[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),
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. 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} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
B(Star), R(2),
B(CallRuntime), U16(Runtime::kCreateArrayLiteralWithoutAllocationSite), R(1), 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: [
]
Reference in New Issue Copy Permalink