Skip to content

V
V8
Switch branch/tag
  1. 05 Mar, 2018 1 commit
  3. 02 Mar, 2018 4 commits
    • Georg Neis's avatar
      [ic] Introduce new IC for storing into array literals. · 2e2860f7
      Georg Neis authored 
      ... and use it in the implementation of array literal spreads,
replacing calls to %AppendElement.

Array spreads in destructuring will be taken care of in a separate CL.

Bug: v8:5940, v8:7446
Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0
Reviewed-on: https://chromium-review.googlesource.com/915364
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51709}
      2e2860f7
    • Georg Neis's avatar
      Reland "[parsing] inline ArrayLiteral creation for spread calls" · 82345e9f
      Georg Neis authored 
      This reverts commit f48e7349.

Reason for revert: innocent!!

Original change's description:
> Revert "[parsing] inline ArrayLiteral creation for spread calls"
> 
> This reverts commit 93fc3841.
> 
> Reason for revert: may break node.js integration
> 
> Original change's description:
> > [parsing] inline ArrayLiteral creation for spread calls
> > 
> > Instead of using runtime calls to generate the Array Literal passed to
> > %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> > list of arguments, and perform spreads using the interpreter mechanism for
> > spreading in ArrayLiterals (thus, the spreading becomes inline). This
> > array literal is still passed to %reflect_call / %reflect_construct as
> > before.
> > 
> > This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> > half, and will likely improve further once
> > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
> > 
> > BUG=v8:7446
> > R=​neis@chromium.org, adamk@chromium.org
> > 
> > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> > Reviewed-on: https://chromium-review.googlesource.com/939587
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#51678}
> 
> TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org
> 
> Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:7446
> Reviewed-on: https://chromium-review.googlesource.com/945769
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51682}

TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org

Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945808Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51686}
      82345e9f
    • Sigurd Schneider's avatar
      Revert "[parsing] inline ArrayLiteral creation for spread calls" · f48e7349
      Sigurd Schneider authored 
      This reverts commit 93fc3841.

Reason for revert: may break node.js integration

Original change's description:
> [parsing] inline ArrayLiteral creation for spread calls
> 
> Instead of using runtime calls to generate the Array Literal passed to
> %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> list of arguments, and perform spreads using the interpreter mechanism for
> spreading in ArrayLiterals (thus, the spreading becomes inline). This
> array literal is still passed to %reflect_call / %reflect_construct as
> before.
> 
> This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> half, and will likely improve further once
> https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
> 
> BUG=v8:7446
> R=​neis@chromium.org, adamk@chromium.org
> 
> Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> Reviewed-on: https://chromium-review.googlesource.com/939587
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51678}

TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org

Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945769Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51682}
      f48e7349
    • Caitlin Potter's avatar
      [parsing] inline ArrayLiteral creation for spread calls · 93fc3841
      Caitlin Potter authored 
      Instead of using runtime calls to generate the Array Literal passed to
%reflect_call / %reflect_construct, we create an ArrayLiteral from the
list of arguments, and perform spreads using the interpreter mechanism for
spreading in ArrayLiterals (thus, the spreading becomes inline). This
array literal is still passed to %reflect_call / %reflect_construct as
before.

This cuts the runtime for bench-spread-call.js -> testSpread roughly in
half, and will likely improve further once
https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.

BUG=v8:7446
R=neis@chromium.org, adamk@chromium.org

Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
Reviewed-on: https://chromium-review.googlesource.com/939587
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51678}
      93fc3841
  5. 28 Nov, 2017 1 commit
  7. 17 Nov, 2017 1 commit
  9. 10 Nov, 2017 2 commits
  11. 31 Oct, 2017 2 commits
  13. 19 Oct, 2017 1 commit
  15. 07 Sep, 2017 1 commit
  17. 27 Jul, 2017 1 commit
  19. 25 Jul, 2017 1 commit
  21. 24 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Add IC support for Call/ConstructWithSpread. · 5ee1b7ad
      Benedikt Meurer authored 
      Properly hook up the (existing) IC slots for the CallWithSpread and
ConstructWithSpread bytecodes, and change the interpreter to collect
feedback (call counts and regular target function feedback) for those.
There's no integration with the Array constructor yet, since that
requires some yak shaving to thread through the AllocationSite to the
Array constructor stub. Once we have a solution for that, we can also
remove the current code duplication in the Call/Construct IC logic.

Also properly hook up the newly available feedback in TurboFan. This
will fix not only the missing target feedback, but more importantly
the tear-up decisions for optimization are correct now in the presence
of spread calls, and even more importantly the inlining heurstic has
proper call frequencies for those.

Some follow-up changes will be necessary to make sure we use the
feedback even for corner cases that aren't handled properly yet. Also
we should consider collecting feedback about the map of the spread
at some point to be able to always inline the spread calls.

Bug: v8:6399, v8:6527, v8:6630
Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00
Reviewed-on: https://chromium-review.googlesource.com/582647Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46832}
      5ee1b7ad
  23. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored 
      This reverts commit a2fcdc7c.

Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)

Original change's description:
> [runtime] Move profiler ticks from SFI to feedback vector
> 
> Instead of counting profiler ticks on the shared function info (which is
> shared between native contexts), count them on the feedback vector
> (which is not). This allows us to continue pushing optimization
> decisions off the SFI, onto the feedback vector.
> 
> Note that a side-effect of this is that ICs don't have to walk the stack
> to reset profiler ticks, as they can access the feedback vector directly
> from their feedback nexus.
> 
> Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
> Reviewed-on: https://chromium-review.googlesource.com/544888
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46411}

TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
Reviewed-on: https://chromium-review.googlesource.com/574227
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  25. 12 Jul, 2017 1 commit
  27. 05 Jul, 2017 1 commit
  29. 10 May, 2017 1 commit
  31. 08 May, 2017 2 commits
    • Ross McIlroy's avatar
      Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector" · fd749344
      Ross McIlroy authored 
      This reverts commit 662aa425.

Reason for revert: Crashing on Canary
BUG=chromium:718891

Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
> 
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
> 
> Original patch by Michael Stanton <mvstanton@chromium.org>
> 
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
> 
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}

TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246

Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
      fd749344
    • Adam Klein's avatar
      Skip hole initialization of lexical variables when possible · ededfcd2
      Adam Klein authored 
      This patch expands scope analysis to skip hole initialization
when it can be determined statically that no hole checks will
be generated at runtime.

Two conditions must be met to safely eliminate hole initialization:
  - There must not exist a VariableProxy referencing this Variable
    whose HoleCheckMode is kRequired
  - The Variable must be stack allocated; any other allocation implies
    that it may be accessed from not-yet-analyzed scopes (other modules,
    inner functions, or eval code) and that code may require
    hole checks.

The new logic required removing debug code in full-codegen which is
now incorrect in some cases.

Also fixed Variable's bitfield helpers to take no more space than needed.

Bug: chromium:651637
Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
Reviewed-on: https://chromium-review.googlesource.com/494006
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45170}
      ededfcd2
  33. 04 May, 2017 2 commits
    • Caitlin Potter's avatar
      [es6] don't use do-expressions to desugar ES6 classes · c6540ab1
      Caitlin Potter authored 
      Removes the do-expression wrapping, modifies BytecodeGenerator change
to enter a class literal's block scope if needed.

This does not solve the actual bug in v8:6322, but helps mitigate it in
simple cases. The bug is caused by BytecodeGenerator not allocating a
large enough array of context registers to hold its entire stack,
allowing non-context registers to be overwritten during PushContext and
PopContext bytecodes.

Nevertheless, I like the idea of not depending on do-expressions when
possible, so I think it's worth doing anyways.

BUG=v8:6322
R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org

Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
Reviewed-on: https://chromium-review.googlesource.com/491074
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarDaniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45110}
      c6540ab1
    • Ross McIlroy's avatar
      Reland: [TypeFeedbackVector] Store optimized code in the vector · 662aa425
      Ross McIlroy authored 
      Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org

Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
      662aa425
  35. 02 May, 2017 2 commits
  37. 27 Apr, 2017 1 commit
    • cbruni's avatar
      [runtime] Ensure slow properties for simple {__proto__:null} literals. · 3f73fecb
      cbruni authored 
      With this CL we reduce the difference between directly using a null prototype
in a literal or using Object.create(null).
- The EmitFastCloneShallowObject builtin now supports cloning slow
  object boilerplates.
- Unified behavior to find the matching Map and instantiating it for
  Object.create(null) and literals with a null prototype.
- Cleanup of literal type parameter of CompileTimeValue, now in sync with
  ObjectLiteral flags.

Review-Url: https://codereview.chromium.org/2445333002
Cr-Commit-Position: refs/heads/master@{#44941}
      3f73fecb
  39. 18 Apr, 2017 1 commit
  41. 01 Feb, 2017 1 commit
  43. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored 
      They have the same lifetime. It's a match!

Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.

A follow-on CL removes even more parser infrastructure related to this count.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  45. 25 Jan, 2017 1 commit
  47. 23 Jan, 2017 1 commit
  49. 18 Jan, 2017 2 commits