Skip to content

V
V8
Switch branch/tag
  1. 24 Sep, 2020 2 commits
  3. 22 Sep, 2020 1 commit
  5. 08 Sep, 2020 1 commit
  7. 28 Aug, 2020 1 commit
    • Marja Hölttä's avatar
      [IC] Clarify receiver vs holder vs lookup start object · 5a6ff768
      Marja Hölttä authored 
      LoadICParameters already has separate fields for receiver and holder,
though, in practice, they were always equal. Moreover, the holder didn't
mean holder, but the lookup start object.

This CL makes parts of the IC layer reusable for cases where they are
not equal, by clarifying whether we're accessing the receiver, the
lookup_start_object, or the holder.

List of changes:

StoreICParameters:
- Detached from LoadICParameters, now they are independent classes.

LoadICParameters:
- Renamed holder to lookup_start_object.

TryProbeStubCache:
- Renamed receiver to lookup_start_object.

LoadIC:
LoadIC_BytecodeHandler:
LoadIC_NoFeedback:
KeyedLoadIC:
KeyedLoadICGeneric:
KeyedLoadICPolymorphicName:
- These won't be reused in the receiver != lookup_start_object case,
so added asserts that receiver == lookup_start_object.

TryMonomorphicCase:
HandlePolymorphicCase:
LoadIC_Noninlined:
GenericElementLoad:
- Renamed receiver_map param to lookup_start_object_map. The callers
either assert receiver == lookup_start_object, or read the map from the
lookup start object.

GenericPropertyLoad:
- Renamed receiver param to lookup_start_object.
- Renamed receiver_map param to lookup_start_object_map. The callers
either assert receiver == lookup_start_object, or read the map from the
lookup start object.

CallGetterIfAccessor:
- Added the holder parameter and used it accordingly.


Bug: v8:9237
Change-Id: I27aca08f58bd66cc9bd1b1baf9f1ff5565d795eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362918
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69606}
      5a6ff768
  9. 17 Aug, 2020 1 commit
  11. 10 Jul, 2020 1 commit
  13. 04 Mar, 2020 1 commit
  15. 18 Dec, 2019 1 commit
    • Leszek Swirski's avatar
      Reland "[ic] Load name/context lazily in LdaNamedProperty" · b21cda74
      Leszek Swirski authored 
      This reverts commit 5377e72c.

Reason for revert: Looks like the relevant graphs didn't recover after
this revert, which suggests that the regression was an unrelated
secondary effect. Relanding the original change since the revert did
cause some microbenchmark regressions.

Original change's description:
> Revert "[ic] Load name/context lazily in LdaNamedProperty"
> 
> This reverts commit 347092ac.
> 
> Not a clean revert, since other changes got baked on top, but rather
> a manual removal of LoadLazyICParameters.
> 
> Reason for revert: Seems to actually regress bindings perf tests (see
> bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
> seem to improve performance elsewhere, and increases complexity.
> 
> Original change's description:
> > [ic] Load name/context lazily in LdaNamedProperty
> >
> > Introduces LazyLoadICParameters which allow a LazyNode for context and
> > name. These aren't used on the fast path, so we want to avoid reading
> > them for both performance and register pressure reasons.
> >
> > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62539}
> 
> # Not skipping CQ checks because original CL landed > 1 day ago.
> 
> Bug: chromium:981797
> Bug: chromium:982630
> Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65205}

TBR=leszeks@chromium.org,verwaest@chromium.org

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

Bug: chromium:981797, chromium:982630, v8:10059
Change-Id: I13754de06c83439e03e22cfaa7a14ce454076db9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973730Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65499}
      b21cda74
  17. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "[ic] Load name/context lazily in LdaNamedProperty" · 5377e72c
      Leszek Swirski authored 
      This reverts commit 347092ac.

Not a clean revert, since other changes got baked on top, but rather
a manual removal of LoadLazyICParameters.

Reason for revert: Seems to actually regress bindings perf tests (see
bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
seem to improve performance elsewhere, and increases complexity.

Original change's description:
> [ic] Load name/context lazily in LdaNamedProperty
>
> Introduces LazyLoadICParameters which allow a LazyNode for context and
> name. These aren't used on the fast path, so we want to avoid reading
> them for both performance and register pressure reasons.
>
> Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62539}

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

Bug: chromium:981797
Bug: chromium:982630
Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65205}
      5377e72c
  19. 19 Nov, 2019 1 commit
  21. 13 Nov, 2019 1 commit
  23. 11 Nov, 2019 1 commit
  25. 31 Oct, 2019 1 commit
  27. 10 Oct, 2019 1 commit
  29. 01 Oct, 2019 1 commit
  31. 17 Sep, 2019 1 commit
  33. 13 Sep, 2019 1 commit
  35. 12 Sep, 2019 1 commit
  37. 10 Sep, 2019 1 commit
    • Leszek Swirski's avatar
      [csa] Merge in- and out-of-object store paths · 8bc54052
      Leszek Swirski authored 
      Rather than duplicating code paths for in- and out-of-object stores,
have one code path which checks whether it needs to load the property
store (and change the storage location to the HeapNumber value for
unboxed doubles).

As a drive-by, change the representation dispatch into a switch, and
inline the representation checks into that switch, to make explicit
what checks for what and which paths transform the value. Also, TNodify
some of the surrounding functions.

Change-Id: Ia1bf698b4cec3ffce9aaa5732cda2e3be9efd8e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795345Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63652}
      8bc54052
  39. 05 Sep, 2019 1 commit
    • Leszek Swirski's avatar
      Reland^2 "[ic] In-place Double -> Tagged transitions"" · 470e6857
      Leszek Swirski authored 
      This is a reland of 981aafaf

It adds double checks to LoadFieldByIndex in the optimizing compiler, which
are likely the source of the crashes.

Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a.
> This is a reland of 7e1fbe8f.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}

TBR=verwaest@chromium.org

Bug: v8:9606
Bug: chromium:997989
Change-Id: Iccfff8e5c6306c9ee4f6c62767dce883b1c6f743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784288Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63582}
      470e6857
  41. 04 Sep, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "Reland "[ic] In-place Double -> Tagged transitions"" · b293533e
      Leszek Swirski authored 
      This reverts commit 981aafaf.

Reason for revert: Still crashing on Canary.

Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a.
> This is a reland of 7e1fbe8f.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}

TBR=leszeks@chromium.org, verwaest@chromium.org, tebbi@chromium.org

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

Bug: v8:9606
Bug: chromium:997989
Change-Id: Ic95166e67df68e84a524dffd8155121c3ff6aa13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784283
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63550}
      b293533e
  43. 02 Sep, 2019 1 commit
  45. 29 Aug, 2019 1 commit
  47. 23 Aug, 2019 2 commits
  49. 05 Aug, 2019 1 commit
    • Mythri A's avatar
      Reland "[ic] Don't transition to premonomorphic state" · 2999cea5
      Mythri A authored 
      This is a reland of 159df248

Original change's description:
> [ic] Don't transition to premonomorphic state
> 
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
> 
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
> 
> 
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}

Change-Id: Ica7eb65649615c2f8410d5b815a98b55cb1cfc4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731000
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63082}
      2999cea5
  51. 01 Aug, 2019 2 commits
  53. 05 Jul, 2019 1 commit
  55. 13 Jun, 2019 1 commit
  57. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored 
      This is a reland of 4b86fea5 with
copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
(bug led to holes in new space, which was crashing reproducibly
on the ia32 bot).

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

Tbr: petermarshall@chromium.org
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored 
      This reverts commit 4b86fea5.

Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
> 
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
> 
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
> 
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
> 
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org

Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored 
      As the next step in supporting huge typed arrays in V8, this moves the
external/data pointer from the FixedTypedArrayBase backing store to the
JSTypedArray instance itself, and replaces the special backing stores
with a plain ByteArray (removing all the code for the FixedTypedArrayBase
class hierarchy). By doing so, we can drastically simplify the system
around typed arrays.

Note: Several places in the code base used to check the instance type
of the elements backing store of a JSTypedArray instead of checking the
elements kind on the JSTypedArray map directly. Those had to be fixed,
since the backing store is now always a ByteArray.

Drive-by-fix: Move all the typed elements access related code into the
elements.cc file to properly encapsulate the accesses.

Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  59. 21 May, 2019 1 commit
  61. 07 May, 2019 1 commit
    • Mythri A's avatar
      Reland [ic] Remove the check for fast prototypes in LoadIC_Uninitialized · 9fe37d23
      Mythri A authored 
      This is a reland of d14ed12e
with fix for test failures in lite mode.

When handling load named properties (without feedback vectors) we used
to miss to runtimes if the prototypes aren't set. This was because we
wanted to give the prototype a chance to become fast, since most prototypes
start in slow mode but move to fast after the initial setup. Though this
check is not really useful when we don't have feedback vectors, and once
feedback vectors are allocated we will turn the prototypes fast anyway.

Bug: v8:8394, v8:8860
Change-Id: I5c7b5061e1d9068c72d6f0eea47517880940a054
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591772Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61267}
      9fe37d23
  63. 12 Apr, 2019 2 commits
  65. 04 Apr, 2019 1 commit
  67. 29 Mar, 2019 1 commit