Skip to content

V
V8
Switch branch/tag
  1. 14 Jan, 2020 1 commit
  3. 13 Jan, 2020 2 commits
  5. 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
  7. 09 Jan, 2020 1 commit
  9. 07 Jan, 2020 1 commit
  11. 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
  13. 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
  15. 26 Nov, 2019 2 commits
    • Suraj Sharma's avatar
      Modify the DCheck to avoid failures. · 2174ba9f
      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: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65185}
      2174ba9f
    • Jakob Kummerow's avatar
      More LookupIterator fixes after r65078 · 3ac7a3e5
      Jakob Kummerow authored 
      (1) One more place in ic.cc must guard against "lookup->name()" calls
when the LookupIterator might be in indexed mode.

(2) Rather than burdening LookupIterator users with specifying
"kGuaranteedNoTypedArray", we can do the corresponding calculation in
the LookupIterator itself, which makes it robust towards any callers
that haven't been updated (specifically, in Object.values).

Bug: chromium:1027461,chromium:1028213
Change-Id: I76b5d08e309fc2a694955b537adbeb5a30e681f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936474Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65177}
      3ac7a3e5
  17. 25 Nov, 2019 3 commits
  19. 22 Nov, 2019 1 commit
  21. 20 Nov, 2019 2 commits
  23. 19 Nov, 2019 2 commits
  25. 15 Nov, 2019 2 commits
  27. 14 Nov, 2019 1 commit
  29. 13 Nov, 2019 1 commit
  31. 12 Nov, 2019 2 commits
  33. 11 Nov, 2019 3 commits
  35. 06 Nov, 2019 1 commit
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored 
      Design doc: bit.ly/v8-repl-mode

This CL adds a new REPL mode that can be used via
DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
of 'let' bindings at the moment. Example:

REPL Input 1: let x = 21;
REPL Input 2: let x = 42;

This would normally throw a SyntaxError, but works in REPL mode.

The implementation is done by:
  - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
    and script {Scope}.
  - Each global let declaration still gets a slot reserved in the
    respective {ScriptContext}.
  - When a new REPL mode {ScriptContext} is created, name clashes
    for let bindings are not reported as errors.
  - Declarations, loads and stores for global let in REPL mode are
    now "load/store global" instead of accessing their respective
    context slot directly. This causes a lookup in the ScriptContextTable
    where the found slot for each name is guaranteed to be the same
    (the first one).

Bug: chromium:1004193, chromium:1018158
Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  37. 05 Nov, 2019 1 commit
  39. 01 Nov, 2019 2 commits
  41. 31 Oct, 2019 2 commits
  43. 30 Oct, 2019 1 commit
  45. 29 Oct, 2019 2 commits
  47. 28 Oct, 2019 1 commit
  49. 23 Oct, 2019 2 commits