Skip to content

V
V8
Switch branch/tag
  1. 20 Nov, 2020 1 commit
    • Frank Emrich's avatar
      [dict-proto] Add support for ordered property dicts, pt.5 · 4d7fcea2
      Frank Emrich authored 
      This CL adds partial support for objects whose slow mode dictionaries
are OrderedNameDictionaries. This is the case for all slow mode objects
if V8_DICT_MODE_PROTOTYPES is enabled.

Specifically, this CL contains bailouts to the runtime in places where
the subsequent CSA or Torque code may have to access property
dictionaries.
These bailouts only happen if V8_DICT_MODE_PROTOTYPES is set, in which
case the property dictionaries are of type OrderedNameDictionary, which
cannot be handled by most CSA/Torque code.

The idea is that these bailouts are temporary and will all be removed
once we've implemented the actuall dictionary accesses in CSA/Torque.

Bug: v8:7569, v8:11167
Change-Id: I8308b2f8ba2d4dbf7918da42f995ae270c825fff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545711
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71311}
      4d7fcea2
  3. 11 Nov, 2020 1 commit
  5. 20 Oct, 2020 1 commit
    • Marja Hölttä's avatar
      [super ic] Fix receiver type · 3773e46e
      Marja Hölttä authored 
      With non-super loads (receiver == lookup_start_object), we don't hit
the code in AccessorAssembler::GenericPropertyLoad calling
CSA::TryGetOwnProperty if the receiver (the lookup_start_object) is a
SMI.

But with super property loads, if we set up lookup_start_object the
right way, we will hit this code.

The code was assuming receiver is a HeapObject, which is too
restrictive. The receiver is only used for the accessor call, so
it's ok to make the type more generic.

Bug: v8:9237, chromium:1139786
Change-Id: I3167ccfb54a49ac1c401040a6f02fc1f3b98d9d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484366Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70647}
      3773e46e
  7. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored 
      CodeAssembler::Parameter now takes a Type template parameter and
performs a checked cast to it. There is also UncheckedParameter which
returns a TNode but doesn't check the cast. The original Parameter
method is still there as UntypedParameter.

Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
cast is performed inside Parameter. Since Parameter is not a macro,
this means it cannot see the original expression or its file name and
line number. So the error messages are vaguely useful, Parameter<T>()
takes a SourceLocation parameter which with a default value of
SourceLocation::Current(), which at least gives us the file name and
line number for the error message.

Bug: v8:6949, v8:10933
Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  9. 29 Sep, 2020 1 commit
  11. 24 Sep, 2020 2 commits
  13. 22 Sep, 2020 1 commit
  15. 14 Sep, 2020 1 commit
  17. 10 Sep, 2020 2 commits
  19. 08 Sep, 2020 2 commits
  21. 02 Sep, 2020 1 commit
  23. 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
  25. 13 Aug, 2020 1 commit
  27. 03 Aug, 2020 1 commit
  29. 29 Jul, 2020 1 commit
  31. 24 Jul, 2020 1 commit
  33. 04 Jun, 2020 1 commit
    • Mythri A's avatar
      [ic] Fix a bug in StoreOwnIC when storing NaN values · b6133551
      Mythri A authored 
      We use StoreOwnIC to initialize the object after creating a new object
with CreateObjectLiteral. CreateObjectLiteral stores kHoleNaNInt64
to indicate an uninitialized double field. When we actually try
to store a NaN value into that field later using StoreOwnIC, IC avoids
actually storing the new value since the existing value is "same as"
the value we try to write. The float comparison treats all NaNs as
equal. In this particular case, we should actually store the new value
since kHoleNaNInt64 value is used to represent an uninitialized field.

This cl just stores the new value even when the existing value is same
as the new value for double fields. The check is still required to
correctly track const fields.

Bug: chromium:1082293
Change-Id: Ib37061802f2403545cffa6d6fef08be074b0825d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228886Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68167}
      b6133551
  35. 18 May, 2020 1 commit
  37. 30 Apr, 2020 1 commit
  39. 15 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      [turbofan] Avoid megamorphic loads for zero-map mono/polymorphic sites · 8428feed
      Leszek Swirski authored 
      Soft-deopt for mono/polymorphic property accesses that don't have any
maps, and only allow zero-map feedback to be monomorphic. This makes
sure we only emit a megamorphic LoadIC builtin call if the IC was
actually megamorphic.

JSGenericLowering assumed that zero maps meant that a load site is
megamorphic. However, it can be the case that the call-site is
monomorphic or polymorphic, and the maps had died. In this case we don't
want to call the megamorphic IC builtin, as on a stub cache miss we
fallback to a normal LoadIC miss, which can record mono/polymorphic
feedback in the IC. After this, we'll enter a miss loop in the
megamorphic load builtin, and worse the LoadIC assumes that there's
something "wrong" with the feedback, so it'll keep trying to reconfigure
the handler (possibly allocating new load handlers if this is a
prototype field access).

As a drive-by, rewrite GetRelevantReceiverMaps to be an in-place
filtering of the maps rather than copying them.

Change-Id: I0c25bfa606367fa81c43223bbd56cdadb5e789ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150586Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67152}
      8428feed
  41. 20 Mar, 2020 1 commit
  43. 04 Mar, 2020 1 commit
  45. 19 Feb, 2020 2 commits
  47. 13 Jan, 2020 2 commits
  49. 10 Jan, 2020 2 commits
    • Santiago Aboy Solanes's avatar
      [cleanup][CSA] TNodify LoadPropertyFromFastObject and related functions · 68376676
      Santiago Aboy Solanes authored 
      Related ones are TryGetOwnProperty and CallGetterIfAccessor.

Bug: v8:10021
Change-Id: I1b65c4260ab48b4431fa2b84a8be5789f24fa800
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993960
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65704}
      68376676
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored 
      This change moves the definitions of the bitfield flags used by Symbol
and Map to Torque. Symbol could directly follow the pattern established
by SharedFunctionInfo, but Map required some other changes:
- Until now, Torque bitfield definitions have required unsigned types. I
  thought that this would be the least-surprising behavior, since we
  never sign-extend when decoding bitfield values. However, I believe
  that the amount of churn involved in making ElementsKind be unsigned
  outweighs the benefit we were getting from this restriction (and
  similar difficulties are likely to arise in converting other bitfield
  structs to Torque), so this CL updates Torque to allow signed bitfield
  values.
- If we try to make Map extend from all of the generated classes that
  define its flags, we end up with class sizing problems because some
  compilers only apply empty base class optimization to the first in a
  row of empty base classes. We could work around this issue by
  generating macros instead of classes, but I took this as an
  opportunity for a minor clean-up instead: rather than having bitfield
  definitions for several different bitfield structs all jumbled
  together in Map, they can be split up. I think this makes the code a
  little easier to follow, but if others disagree I'm happy to implement
  macro generation instead.

Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  51. 07 Jan, 2020 1 commit
  53. 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
  55. 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
  57. 22 Nov, 2019 1 commit
  59. 20 Nov, 2019 2 commits
  61. 19 Nov, 2019 1 commit
  63. 14 Nov, 2019 1 commit
  65. 13 Nov, 2019 1 commit