- 28 Jul, 2020 1 commit
-
-
Mythri A authored
1. Adds a flag to specify if minimorphic accesses should be optimized using dynamic map checks operators. This flag is disabled by default. 2. Builds the PropertyAccessInfo from handlers instead of reading it from maps for minimorphic accesses 3. Uses DynamicMapChecks operator to lower the minimorphic accesses. Bug: v8:10582, v8:9684 Change-Id: I0b7b26b876f9ad12d6fc38788137b66ee6455aeb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241524Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69112}
-
- 27 Jul, 2020 1 commit
-
-
Sathya Gunasekaran authored
This flag's name is slightly incorrect as it is possible to have more maps than this in the feecback vector. This flag doesn't account for deprecated maps in the feedback vector. To make this explicit, we change the flag to indicate that this only counts valid maps. Bug: v8:10582 Change-Id: Ib0cc425a03d590bb21184fc6b104d0ebee1d5b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319992Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69075}
-
- 06 Jul, 2020 1 commit
-
-
Leszek Swirski authored
This will allow it to take an OffThreadIsolate in the future, without requiring GetIsolate on SharedFunctionInfo. Change-Id: I7db56d5f0587585f829b26e60683c133760d8ff1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282534Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68696}
-
- 01 Jul, 2020 1 commit
-
-
Georg Neis authored
Also fix a typo in a log message. Change-Id: I247e5347b7f7d71b08630489896da463dd76b8a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2277885 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68635}
-
- 25 Jun, 2020 1 commit
-
-
Mike Stanton authored
Currently the FeedbackVector uses arrays in slots that are polymorphic, usually in a <map, handler> tuple pattern. Helper functions try to re-use an existing array if it's already in place. For Concurrent TurboFan, it would be far better if these FixedArrays were immutable. We could then count on semantic correctness when harvesting their information from a background thread without locking. Additionally, the arrays should always be initialized fully before being set in place. Bug: v8:7790 Change-Id: I81eae3bda48c2d0d8eea41d1bc9c62afb7e619d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264364Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#68532}
-
- 10 Jun, 2020 1 commit
-
-
Jakob Gruber authored
This is a reland of 8748613f, fixing an issue accessing binary op's BinaryOperationHints. Original change's description: > [compiler] Hook in binary op builtins with feedback in generic lowering > > If --turbo-nci is enabled, use binary op builtins with feedback > collection during generic lowering. > > Bug: v8:8888 > Change-Id: I307dc742488982bdc68006be5bcd1da8e68768f5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228614 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68227} Bug: v8:8888,chromium:1092553 Change-Id: I1356659d65a5e46bc57bb6c0ebe2e9e86cb8be81 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237128 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68288}
-
- 08 Jun, 2020 2 commits
-
-
Leszek Swirski authored
This reverts commit 8748613f. Reason for revert: MSAN failures (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/32760?) Original change's description: > [compiler] Hook in binary op builtins with feedback in generic lowering > > If --turbo-nci is enabled, use binary op builtins with feedback > collection during generic lowering. > > Bug: v8:8888 > Change-Id: I307dc742488982bdc68006be5bcd1da8e68768f5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228614 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68227} TBR=neis@chromium.org,jgruber@chromium.org Change-Id: I635b1a5a28b25ce29e4f8bc23eb52841885b0cdf No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8888 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235535Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68229}
-
Jakob Gruber authored
If --turbo-nci is enabled, use binary op builtins with feedback collection during generic lowering. Bug: v8:8888 Change-Id: I307dc742488982bdc68006be5bcd1da8e68768f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228614 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68227}
-
- 03 Jun, 2020 1 commit
-
-
Mythri A authored
This is a followup of the cl [1] that fixes a bug where bytecode was getting flushed when allocating feedback vector. The fix added IsCompiledScope before allocating a new feedback vector. We now pass IsCompiledScope to JSFunction::EnsureFeedbackVector. This makes it explicit that EnsureFeedbackVector expects a function that is compiled and the bytecode shouldn't be flushed during the allocation.Also adds a test. [1] https://chromium-review.googlesource.com/c/v8/v8/+/2218066 Bug: v8:10560 Change-Id: I552c449a57555dffa625b2e4efa04c2c276fc0b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222347 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68142}
-
- 02 Jun, 2020 1 commit
-
-
Jakob Gruber authored
If --turbo-nci is enabled, use compare op builtins with feedback collection during generic lowering. Bug: v8:8888 Change-Id: I886020e2ee280f65388d9987c70958546f99e0f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215821Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68100}
-
- 28 May, 2020 1 commit
-
-
Mythri A authored
Allocating a new feedback vector happens in two steps: We create an empty structure and then initialize the array based on the FeedbackMetadata.When allocating a new feedback array we could trigger a GC which might flush the bytecode and associated feedback metadata. This shouldn't happen in normal cases, because we either allocate feedback vector after compilation or when we reach the expected budget. In both cases, the age of the feedback vector should be 0 and hence bytecode shouldn't be flushed. However, with debugger enabled we may allocate feedback vectors even when the bytecode array is old for example: when we enable precise invocation counters. This also causes issues in tests with --stress-flush-bytecode. In the stress mode we flush bytecode without considering the age. Holding on to the feedback metadata prevents crashes in such cases. Bug: v8:10560 Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066 Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68052}
-
- 08 Apr, 2020 1 commit
-
-
Mythri A authored
For keyed stores we recompute handlers when we see a new map so that we could transition to the most general elements kind we have seen so far. When recomputing these handlers we drop the deprecated maps. Instead we could TryUpdate deprecated maps. This would be inline with what TurboFan does and also may be better for performance. Bug: chromium:1053939 Change-Id: Id38b60538d56f4b376460c0faece20768a18f25f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130129 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67060}
-
- 02 Apr, 2020 1 commit
-
-
Mythri A authored
For keyed stores we recompute handlers based on the receiver maps we have seen. This is done so that we can transition to the most generic elements kind we have seen so far. When we recompute this handlers we get a new prototype validity cell and ignore the existing cell. This leads to incorrect behaviour if the cell was invalid. Recomputing the handler may be extra work which is not worth doing at this point. So we just reuse the existing validity cell and let the IC recompute the handler if we see the map again. Bug: chromium:1053939 Change-Id: Ifc891d70f5a4b8b774238e12fb40e29b4d174e37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122032 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66963}
-
- 16 Mar, 2020 1 commit
-
-
Mythri A authored
With the current flow, it is difficult to easily get the output of --trace-opt, --trace-deopt and --trace-osr from Android devices. These flags log to stdout and on Android it is difficult to get this output that preserves the formatting. This cl redirects them to a file when --redirect-code-traces is specified. Change-Id: I8ea1f083d0ee4577f9d70cfd2d7cb2823fd1a6c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089931 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66722}
-
- 03 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Add the remaining missing templatizations to allow an initial wiring in of the off-thread factory into streaming compilation finalization. The off-thread finalization is behind a flag, disabled by default: --finalize-streaming-on-background When the flag is enabled, background tasks will perform perform the finalization during their background execution, and will release the parser and compilation jobs once they are no longer needed. The implementation is complete enough for performance testing, but not enough for launch. Notably, there is no support for: * Class boilerplates (the code is marked unreachable), * Exceptions during finalization, i.e. parse/compile warnings/errors, * Allocation sampling, * Logging, * Asm.js, * Parallel complication tasks * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()") This patch also adds some tracing events for the various stages of the off-thread finalization (including the main-thread merge) for further performance improvements. Bug: chromium:1011762 Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66566}
-
- 29 Feb, 2020 1 commit
-
-
Mike Stanton authored
We can make better inlining decisions in TurboFan if the CallIC will provide the feedback that it's seen multiple closures that share the same SharedFunctionInfo. This is not difficult to do, and it fixes some frustrating performance cliffs. Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his project a year ago. Bug: v8:2206, v8:10100 Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66512}
-
- 26 Nov, 2019 1 commit
-
-
Suraj Sharma authored
Now since we also encode KeyedAccessStoreMode information in the slow handler for some cases, the DCheck can result in failure.The Check can result in failures for other cases of StoreSlow. Removing the DCHECK altogether, now verifying the correctness of the behavior using the Kind Bits of the Handler in the method GetKeyedAccessStoreMode. Bug: chromium:1027025, chromium:1028085 Change-Id: I59acedbb499930e67ae5999d4bfd0f040a34b46e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929408Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65185}
-
- 20 Nov, 2019 2 commits
-
-
Suraj Sharma authored
This is a reland of d46bd852 Original change's description: > [ic] Migrate Code-based handlers to use data driven handler. > > All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow > and KeyedStoreIC_Slow now use data driven handlers > > Bug: v8:9779 > Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Suraj Sharma <surshar@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#64918} Bug: v8:9779 Change-Id: I8fb9359752d6b8e8211c37e15e8f1bf61dd6532a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916684Reviewed-by: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65086}
-
Georg Neis authored
Bug: v8:9989 Change-Id: I6923f99398c0a1c8b447e18e0416a2630a09ee5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924259Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#65065}
-
- 15 Nov, 2019 1 commit
-
-
Maya Lekova authored
This helps reduce the number of false positives encountered by the dead variable analysis in gcmole. TBR=jgruber@chromium.org, verwaest@chromium.org, yangguo@chromium.org Bug: v8:9810 Change-Id: I1a34ccaab340e6abc37832b4ce1a0cabc56fa438 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917146 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64981}
-
- 12 Nov, 2019 2 commits
-
-
Joshua Litt authored
This reverts commit d46bd852. Reason for revert: I suspect this breaks the 'V8 Linux - predictable' bot. Specifically, 'typedarray-copywithin' has been failing since this landed. I am not exactly sure what is wrong from the tests error message, but see this link for more information: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8896980452133814304/+/steps/Check_-_d8__flakes_/0/logs/typedarray-copywithin/0 Original change's description: > [ic] Migrate Code-based handlers to use data driven handler. > > All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow > and KeyedStoreIC_Slow now use data driven handlers > > Bug: v8:9779 > Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Suraj Sharma <surshar@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#64918} TBR=rmcilroy@chromium.org,verwaest@chromium.org,surshar@microsoft.com Change-Id: Id7c2b553f85b46048bed2c633b8bd24098f67147 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9779 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912092Reviewed-by: Joshua Litt <joshualitt@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64922}
-
Suraj Sharma authored
All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow and KeyedStoreIC_Slow now use data driven handlers Bug: v8:9779 Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64918}
-
- 16 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
for "entries", i.e. indices into the backing store (as opposed to "public indices" going into the hash function). This improves consistency and compiler-enforced type safety; no change in behavior is intended. Change-Id: I25e57e3ddcf18a406e2dfbd66786b6980c4e9615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852768 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64317}
-
- 02 Oct, 2019 1 commit
-
-
Mythri A authored
Premonomorphic state was only used for store globals to handle contextual store on a global object [1]. We now handle these differently and we move to fast handlers even without going through premonomorphic state after this cl: https://chromium-review.googlesource.com/c/v8/v8/+/1807356. Also, with lazy feedback this would be a relatively uncommon case anyway. So, we no longer need premonomorphic state. This cl removes this state entirely. [1]: https://bugs.chromium.org/p/v8/issues/detail?id=8712 Bug: v8:8394 Change-Id: I71fb918b82b0c321a9705e32c8fc44e9ec223b38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1833690Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#64085}
-
- 30 Sep, 2019 1 commit
-
-
Suraj Sharma authored
Since slow handler was previously not a Smi. The DCHECK assumed any Smi Handler on this path should be a proxy handler. Now it Checks for both, and should continue if the current handler is a slow handler. Bug: chromium:1008632 Change-Id: I079960894d7320d8d658d0990e8c32db51703206 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1828480Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64052}
-
- 12 Sep, 2019 1 commit
-
-
Victor Gomes authored
Bug: v8:9714 Change-Id: I70c28c3bc2aae6234e55e8a3b176da2035520a67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800567 Commit-Queue: Victor Gomes <victorgomes@google.com> Auto-Submit: Victor Gomes <victorgomes@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63717}
-
- 04 Sep, 2019 1 commit
-
-
Tobias Tebbi authored
This reverts commit 352a154e. Reason for revert: https://crbug.com/999972 Original change's description: > [compiler] improve inlining heuristics: call frequency per executed bytecodes > > TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan > compile time including off-thread, while improving Octane scores by ~2%. > > How things used to work: > > There is a flag FLAG_min_inlining_frequency that limits inlining by > the callsite being sufficiently frequently executed. This call frequency > was measured relative to invocations of the parent (= the function we > originally optimize). At the same time, the limit was very low (0.15), > meaning we mostly relied on the total amount of inlined code > (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining. > > How things work now: > > Instead of measuring call frequency relative to parent invocations, we > should have a measure that predicts how often the callsite in question > will be executed in the future. An obvious attempt at that would be to > measure how often the callsite was executed in absolute numbers in the > past. But depending on how fast feedback stabilizes, it can take more > or less time until we optimize a function. If we just take the absolute > call frequency up to the point in time when we optimize, we would > inline more for functions that stabilize slowly, which doesn't make > sense. So instead, we measure absolute call count per KB of executed > bytecodes of the parent function. > Since inlining big functions is more expensive, this threshold is > additionally scaled linearly with the bytecode-size of the inlinee. > The resulting formula is: > call_frequency > > FLAG_min_inlining_frequency * > (bytecode.length() - FLAG_max_inlined_bytecode_size_small) / > (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small) > > The new threshold is chosen in a way that it effectively limits > inlining, which allows us to increase > FLAG_max_inlined_bytecode_size_cumulative without increasing inlining > in general. > > The reduction in compile time (x64 build) of ~10% was observed in Octane, > ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark. > The hope is that this will reduce CPU-time in real-world situations > too. > The Octane improvements come from inlining more in places where it > matters. > > Bug: v8:6682 > > Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63449} TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6682 chromium:999972 Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63554}
-
- 29 Aug, 2019 1 commit
-
-
Tobias Tebbi authored
TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan compile time including off-thread, while improving Octane scores by ~2%. How things used to work: There is a flag FLAG_min_inlining_frequency that limits inlining by the callsite being sufficiently frequently executed. This call frequency was measured relative to invocations of the parent (= the function we originally optimize). At the same time, the limit was very low (0.15), meaning we mostly relied on the total amount of inlined code (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining. How things work now: Instead of measuring call frequency relative to parent invocations, we should have a measure that predicts how often the callsite in question will be executed in the future. An obvious attempt at that would be to measure how often the callsite was executed in absolute numbers in the past. But depending on how fast feedback stabilizes, it can take more or less time until we optimize a function. If we just take the absolute call frequency up to the point in time when we optimize, we would inline more for functions that stabilize slowly, which doesn't make sense. So instead, we measure absolute call count per KB of executed bytecodes of the parent function. Since inlining big functions is more expensive, this threshold is additionally scaled linearly with the bytecode-size of the inlinee. The resulting formula is: call_frequency > FLAG_min_inlining_frequency * (bytecode.length() - FLAG_max_inlined_bytecode_size_small) / (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small) The new threshold is chosen in a way that it effectively limits inlining, which allows us to increase FLAG_max_inlined_bytecode_size_cumulative without increasing inlining in general. The reduction in compile time (x64 build) of ~10% was observed in Octane, ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark. The hope is that this will reduce CPU-time in real-world situations too. The Octane improvements come from inlining more in places where it matters. Bug: v8:6682 Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63449}
-
- 19 Aug, 2019 4 commits
-
-
Georg Neis authored
Rewrite the reducer in terms of the ordinary keyed-store reducer and reuse the existing serializer machinery for that as well. Bug: v8:7790 Change-Id: I5909739feee1d77dca1827166bad3d2a61561784 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760807Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63254}
-
Georg Neis authored
This is a reland of 29585a06 after removing an incorrect DCHECK. Original change's description: > [turbofan] Various serializer/broker improvements > > They are all somewhat entangled, sorry for the big CL. > > - Brokerize remaining feedback vector slots. > - Introduce Hints::SingleConstant helper. > - Introduce SerializationPolicy enum. > - Eliminate use of nullptr for megamorphic load/store ic feedback. > Instead use the corresponding ProcessedFeedback with an empty list > of maps or the like. new class MegamorphicFeedback. > - Separate processing of feedback from serialization. This eliminates > code duplication. > - Be very careful when clearing hints not to overwrite hints that are > being processed. > - Move AccessInfos out of NamedAccessFeedback. Always store them in > property_access_infos_ map on broker. (This was actually unused > before, somewhat by mistake.) > - Support map inference in concurrent inlining. Rewrite > ElementAccessFeedback such that we can refine it with the set of > inferred maps. > > TBR: mvstanton@chromium.org > Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63232} TBR: mvstanton@chromium.org Bug: v8:7790 Change-Id: Ia4acd31b339a941ee065e1ae4835bb7b85d5685e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758319Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63241}
-
Maya Lekova authored
This reverts commit 29585a06. Reason for revert: Breaks GC stress bots - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24009 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/27281 Original change's description: > [turbofan] Various serializer/broker improvements > > They are all somewhat entangled, sorry for the big CL. > > - Brokerize remaining feedback vector slots. > - Introduce Hints::SingleConstant helper. > - Introduce SerializationPolicy enum. > - Eliminate use of nullptr for megamorphic load/store ic feedback. > Instead use the corresponding ProcessedFeedback with an empty list > of maps or the like. new class MegamorphicFeedback. > - Separate processing of feedback from serialization. This eliminates > code duplication. > - Be very careful when clearing hints not to overwrite hints that are > being processed. > - Move AccessInfos out of NamedAccessFeedback. Always store them in > property_access_infos_ map on broker. (This was actually unused > before, somewhat by mistake.) > - Support map inference in concurrent inlining. Rewrite > ElementAccessFeedback such that we can refine it with the set of > inferred maps. > > TBR: mvstanton@chromium.org > Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63232} TBR=mvstanton@chromium.org,neis@chromium.org Change-Id: I88625d92fddf993db63661666c59af05a47b2b58 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758314Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63237}
-
Georg Neis authored
They are all somewhat entangled, sorry for the big CL. - Brokerize remaining feedback vector slots. - Introduce Hints::SingleConstant helper. - Introduce SerializationPolicy enum. - Eliminate use of nullptr for megamorphic load/store ic feedback. Instead use the corresponding ProcessedFeedback with an empty list of maps or the like. new class MegamorphicFeedback. - Separate processing of feedback from serialization. This eliminates code duplication. - Be very careful when clearing hints not to overwrite hints that are being processed. - Move AccessInfos out of NamedAccessFeedback. Always store them in property_access_infos_ map on broker. (This was actually unused before, somewhat by mistake.) - Support map inference in concurrent inlining. Rewrite ElementAccessFeedback such that we can refine it with the set of inferred maps. TBR: mvstanton@chromium.org Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63232}
-
- 05 Aug, 2019 1 commit
-
-
Georg Neis authored
This reverts commit 9499ec0d. Reason for revert: Breaks lots of stuff, e.g. https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064%20-%20future/9401 Original change's description: > [TurboFan] Brokerize remaining feedback vector slots > > This CL adds new ProcessedFeedback subclasses, corresponding to various IC > types: > > * ForIn > * Comparison ops > * Binary/Unary ops > * InstanceOf > * Calls > > The feedback is gathered at serialization time and used in several places, > namely: > > * Bytecode graph building, > * and its helper class JSTypeHintLowering (with its "early lowering") > * Native context specialization > * JSCallReducer > > Design doc: https://docs.google.com/document/d/1JLG0VFV8xmsAIJexU19xzlbNyP51ONqfo_Gf_2DcPC8/edit?usp=sharing > > Bug: v8:7790 > Change-Id: I53c3d7a17f844384f38c4ee0f0b082c114217a02 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710663 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63028} TBR=mvstanton@chromium.org,neis@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: Id0c4d6651611fc3964010f7615d0ad0485169ebc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735315Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63073}
-
- 01 Aug, 2019 1 commit
-
-
Georg Neis authored
This CL adds new ProcessedFeedback subclasses, corresponding to various IC types: * ForIn * Comparison ops * Binary/Unary ops * InstanceOf * Calls The feedback is gathered at serialization time and used in several places, namely: * Bytecode graph building, * and its helper class JSTypeHintLowering (with its "early lowering") * Native context specialization * JSCallReducer Design doc: https://docs.google.com/document/d/1JLG0VFV8xmsAIJexU19xzlbNyP51ONqfo_Gf_2DcPC8/edit?usp=sharing Bug: v8:7790 Change-Id: I53c3d7a17f844384f38c4ee0f0b082c114217a02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710663 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63028}
-
- 08 Jul, 2019 1 commit
-
-
Nico Hartmann authored
Feedback shall not be updated by the deoptimizer. Although this mechanism exists, it shall not be used if possible. This CL changes how V8 learns from BigInt deopts: Previously we updated feedback on the BinaryOperations in the deoptimizer, now we let the interpreter widen the feedback type from BigInt to Any after the deopt has occurred. Bug: v8:9407 Change-Id: I92e5e733085b433fd8ab452674d02404b81b2796 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687419Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62548}
-
- 26 Jun, 2019 1 commit
-
-
Nico Hartmann authored
This is a reland of 5ff38bae Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} Bug: v8:9213 Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62381}
-
- 25 Jun, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 5ff38bae. Reason for revert: flaky test that is not normally flaky failed. See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531 Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9213 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62364}
-
Nico Hartmann authored
This CL introduces the necessary infrastructure to generate speculative BigInt operations in case of BigInt feedback. In particular, the JSAdd operator is lowered to a speculative call to the BigIntAdd builtin, with a deopt bailout in case of exceptions or violated assumptions. Bug: v8:9213 Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62362}
-
- 12 Jun, 2019 1 commit
-
-
Andrey Lushnikov authored
This was originally reported at https://github.com/GoogleChrome/puppeteer/issues/4545 R=ulan, alph Change-Id: I5134506e56cd40e49b358cd47590913b81013b6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649473 Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62129}
-
- 31 May, 2019 1 commit
-
-
Benedikt Meurer authored
This fixes a problem where ICs for transitioning stores go MEGAMORPHIC if the transition target map dies in between invocations of the IC, which is totally possible, since we only hold on weakly to these transition targets (both from the FeedbackVectors and also from the TransitonArrays). The root problem here was an inconsistency in how the maps and handlers are being reported by the FeedbackVector. On the on hand side the method FeedbackVector::ExtractMaps() will report all receiver maps that are still present (i.e. which haven't died themselves), but then the other method FeedbackVector::FindHandlers() will only report handlers that are still alive (i.e. which in case of transition target maps being used as handlers haven't died yet). If the length of these lists don't match the IC chickens out and goes MEGAMORPHIC. But this is exactly the case with the transitioning stores, where there's no handler anymore, i.e. as can be seen in this simple example: ``` // Flags: --expose-gc function C() { this.x = 1; } new C(); new C(); gc(); // map with the `C.x` property dies new C(); // now the STORE_IC in C goes MEGAMORPHIC ``` So the problem is that we have these two methods that don't agree with each other. Now FeedbackVector::ExtractMaps() is also used by TurboFan and it even reports receiver maps for PREMONOMORPHIC state, which is different from the use case that the ICs need. So I replaced the FeedbackVector::FindHandlers() with a completely new method FeedbackVector::ExtractMapsAndHandlers(), which returns both the maps and handlers, exactly as the ICs need it. And only returns pairs for which both the receiver map and the handler are still alive. This fixes the odd problem that sometimes STORE_ICs going MEGAMORPHIC for no apparent reason. Due to the weakness of the transition target maps, they can still die and cause deoptimizations, but at least TurboFan will now be able to reoptimize again later with the new maps and still generate proper code. Bug: v8:9316 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Change-Id: I74c8b60f792f310dc813f997e69efe9ad434296a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637878 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61948}
-