Skip to content

V
V8
Switch branch/tag
  1. 11 Nov, 2020 1 commit
  3. 27 Oct, 2020 1 commit
    • Mike Stanton's avatar
      [TurboFan] Provide concurrent access to feedback vector · 2288b1f6
      Mike Stanton authored 
      This CL provides synchronized get/set to feedback vector slots.
The FeedbackNexus is set up to use order preserving reads when used
on the background thread, and a lock to ensure coherent read
of information for ICKinds with two slots. The main thread takes
the lock on sets.

This test provides patterns to be followed by concurrent TurboFan.

We don't yet access the FeedbackVector on the background thread.
This CL only makes it safe to do so. The next step will come when
the optimizing compiler begins to query the the vector from the
background thread. Currently, with --concurrent-inlining turned on
this is done in bytecode serialization on the main thread. Without
concurrent inlining, it's also done on the main thread, in both
cases using the FeedbackNexus.

Bug: v8:7790
Change-Id: I49d8b8031190f91a0da1c24f375b6b6d8a9fe038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276210
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70797}
      2288b1f6
  5. 22 Oct, 2020 2 commits
  7. 21 Oct, 2020 1 commit
  9. 20 Oct, 2020 2 commits
  11. 12 Oct, 2020 1 commit
  13. 05 Oct, 2020 1 commit
  15. 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
  17. 29 Sep, 2020 1 commit
  19. 28 Sep, 2020 1 commit
  21. 24 Sep, 2020 2 commits
  23. 22 Sep, 2020 2 commits
  25. 18 Sep, 2020 2 commits
  27. 14 Sep, 2020 1 commit
  29. 10 Sep, 2020 2 commits
  31. 09 Sep, 2020 1 commit
  33. 08 Sep, 2020 2 commits
  35. 02 Sep, 2020 1 commit
  37. 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
  39. 17 Aug, 2020 1 commit
  41. 13 Aug, 2020 1 commit
  43. 11 Aug, 2020 2 commits
  45. 10 Aug, 2020 1 commit
  47. 03 Aug, 2020 1 commit
  49. 29 Jul, 2020 1 commit
  51. 27 Jul, 2020 1 commit
  53. 24 Jul, 2020 1 commit
  55. 14 Jul, 2020 1 commit
  57. 10 Jul, 2020 1 commit
  59. 09 Jul, 2020 1 commit
  61. 04 Jun, 2020 2 commits
    • Nico Hartmann's avatar
      [turbofan] Fix lost exception on BigInt ops · ca54b833
      Nico Hartmann authored 
      Speculative BigInt addition fails to throw the expected exception
when called with non-BigInt inputs when the result of the computation
is unused. In paricular, this CL does:
 - Remove kNoThrow on speculative BigInt operators
 - Fix AddWithFeedback to not lose type feedback if builtin throws
   to elide existing deopt loops
 - Add handling of TypeCheckKind in RepresentationChanger where this
   was previously ignored

Bug: chromium:1073440
Change-Id: I953a5b790fc3b37a6824f0b6546a0488c51fbb3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228493Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68181}
      ca54b833
    • 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