The decision as to whether to optimize an IIFE as oneshot depends on
whether it's outer scope is the script scope. During lazy compile, we
might have discarded scopes which don't need a context between the IIFE
and the script scope, which means we might treat an IIFE as oneshot,
even though initial eager compile treated it as non-oneshot. Both
bytecode flushing and lazy source positions rely on us generating the
same bytecode during lazy compile as eager compile, so we move the
decision into the parser where it happens once and is then stored in
the SFI for any future lazy compiles.
BUG=v8:8395,v8:8510
Change-Id: I88f1e74ad95d47a2636c393ceb1318d7d610055d
Reviewed-on: https://chromium-review.googlesource.com/c/1421841
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58996}
Adding test to confirm that no one-shot optimizations are not done
for functions enclosed in parentheses but not immediately invoked
in an assignment.
Bug: v8:8072
Change-Id: I282132a7cc570b59290f2ec314462be060d48e5a
Reviewed-on: https://chromium-review.googlesource.com/c/1238576
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56763}
This is a reland of eccf186749
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
Bug: v8:8072
Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
Reviewed-on: https://chromium-review.googlesource.com/1245742
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56266}
This reverts commit eccf186749.
Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com
Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8072
Reviewed-on: https://chromium-review.googlesource.com/1245421
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56232}
Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
for one-shot property loads and stores. This CL replaces the runtime
calls with new bytecodes for named property load stores in one-shot code.
the runtime calls needed extra set of consecutive registers and
additional move instructions. This increased the size of
bytecode-array and possibly extended the life time of objects.
By replacing them with NoFeedback bytecodes we avoid these issues.
Bug: v8:8072
Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
Reviewed-on: https://chromium-review.googlesource.com/1196725
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#56211}
IIFE`s within a function are not guaranteed to be executed only once.
They can be called multiple times and compiler can inline them.
Do the one-shot optimizations only for IIFE`s from top-level code.
Bug: v8:8072, chromium:886580
Change-Id: I02370681cc3eab270edcc75ee120ca7ad768ed52
Reviewed-on: https://chromium-review.googlesource.com/1231174
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56024}
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}
This is a reland of 1c48d52bb1.
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}
This reverts commit 1c48d52bb1.
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}
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}
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}
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}
This is a reland of 690bda84eb
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}
This reverts commit 690bda84eb.
Reason for revert: Speculative revert for:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/25372
See more at:
https://github.com/v8/v8/wiki/Blink-layout-tests
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}
TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,yangguo@chromium.org,cbruni@chromium.org,leszeks@chromium.org,verwaest@chromium.org,chandanreddy@google.com
Change-Id: I642164a72453189fd0fe92b69f199f958ce56bef
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1166782
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54955}
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}
