Skip to content

V
V8
Switch branch/tag
  1. 10 Jun, 2022 1 commit
  3. 20 Apr, 2022 1 commit
  5. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored 
      This is a reland of cf93071c

Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}

Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  7. 16 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored 
      This reverts commit cf93071c.

Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview

Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}

TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com

Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored 
      Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit

This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.

In order to not degrade speed, a couple of other changes are required:

The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.

A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.

Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.

Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
  9. 20 Mar, 2020 1 commit
  11. 11 Mar, 2020 1 commit
  13. 10 Feb, 2020 1 commit
  15. 19 Oct, 2017 1 commit
  17. 12 Sep, 2017 2 commits
  19. 27 Jul, 2017 1 commit
  21. 25 Jul, 2017 1 commit
  23. 18 Jul, 2017 1 commit
  25. 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
  27. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored 
      Goal of this CL: explicit return from non-async function has position after
return expression as return position (will unblock [1]).

BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
If one of these methods is called then next generated bytecode will get passed
position. It's general treatment for most cases.
Unfortunately it doesn't work for Returns:
- debugger requires source positions exactly on kReturn bytecode in stepping
  implementation,
- BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
  generates more then one bytecode and general solution will put return position
  on first generated bytecode,
- it's not easy to split BuildReturn function into two parts to allow something
  like following in BytecodeGenerator::VisitReturnStatement since generated
  bytecodes are actually controlled by execution_control().
..->BuildReturnPrologue();
..->SetReturnPosition(stmt);
..->Return();

In this CL we pass ReturnStatement through ExecutionControl and use it for
position when we emit return bytecode right here.

So this CL only will improve return position for returns inside of non-async
functions, I'll address async functions later.

[1] https://chromium-review.googlesource.com/c/543161/

Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
Reviewed-on: https://chromium-review.googlesource.com/560738
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  29. 05 Jul, 2017 1 commit
  31. 10 May, 2017 1 commit
  33. 08 May, 2017 1 commit
    • 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
  35. 04 May, 2017 1 commit
    • 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
  37. 02 May, 2017 2 commits
  39. 10 Apr, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" · 496864f8
      Ross McIlroy authored 
      This relands commit d3e9aade. The original CL was reverted speculatively but didn't cause the buildbot failure.

Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
> 
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
> 
> In the process, adds Smi bytecode variants for all binary operations, adding
>  - MulSmi
>  - DivSmi
>  - ModSmi
>  - BitwiseXorSmi
>  - ShiftRightLogical
> 
> BUG=v8:6194
> 
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}

TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6194

Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8
Reviewed-on: https://chromium-review.googlesource.com/472746Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44511}
      496864f8
  41. 07 Apr, 2017 2 commits
  43. 25 Jan, 2017 1 commit
  45. 24 Jan, 2017 1 commit
  47. 08 Dec, 2016 1 commit
  49. 10 Nov, 2016 1 commit
  51. 04 Oct, 2016 1 commit
  53. 30 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. · 27fe988b
      rmcilroy authored 
      There are only a few occasions where we allocate a register in an outer
expression allocation scope, which makes the costly free-list approach
of the BytecodeRegisterAllocator unecessary. This CL replaces all
occurrences with moves to the accumulator and stores to a register
allocated in the correct scope. By doing this, we can simplify the
BytecodeRegisterAllocator to be a simple bump-pointer allocator
with registers released in the same order as allocated.

The following changes are also made:
 - Make BytecodeRegisterOptimizer able to use registers which have been
   unallocated, but not yet reused
 - Remove RegisterExpressionResultScope and rename
   AccumulatorExpressionResultScope to ValueExpressionResultScope
 - Introduce RegisterList to represent consecutive register
   allocations, and use this for operands to call bytecodes.

By avoiding the free-list handling, this gives another couple of
percent on CodeLoad.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2369873002
Cr-Commit-Position: refs/heads/master@{#39905}
      27fe988b
  55. 14 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Collect invocation counts and compute relative call frequencies. · c7d7ca36
      bmeurer authored 
      Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).

Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.

Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).

See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8

BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
      c7d7ca36
  57. 13 Sep, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Merge {OsrPoll} with {Jump} bytecode. · c9864173
      mstarzinger authored 
      This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.

R=rmcilroy@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2331033002
Cr-Commit-Position: refs/heads/master@{#39384}
      c9864173
  59. 06 Sep, 2016 1 commit
    • leszeks's avatar
      [Interpreter] Remove constant pool type in tests · b28b7e13
      leszeks authored 
      For historical reasons, the interpreter's bytecode expectations tests
required a type for the constant pool. This had two disadvantages:

 1. Strings and numbers were not visible in mixed pools, and
 2. Mismatches of pool types (e.g. when rebaselining) would cause parser
    errors

This removes the pool types, making everything 'mixed', but appending
the values to string and number valued constants. Specifying a pool type
in the *.golden header now prints a warning (for backwards compatibility).

BUG=v8:5350

Review-Url: https://codereview.chromium.org/2310103002
Cr-Commit-Position: refs/heads/master@{#39216}
      b28b7e13
  61. 30 Aug, 2016 1 commit
  63. 23 Aug, 2016 1 commit
  65. 19 Aug, 2016 1 commit
  67. 18 Aug, 2016 1 commit
  69. 08 Aug, 2016 1 commit
  71. 21 Jul, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Avoid accessing on-heap literal in VisitLiteral. · 6b5949a8
      rmcilroy authored 
      Move VisitLiteral to decide what type of literal is being emitted by
checking the raw ASTValue type, instead of the internalized on-heap
value. This is required for concurrent bytecode generation.

As part of this change, the NUMBER AstValue constructor is modified to
try to convert numbers without a dot to SMIs where possible. This is to
maintain the behavior in NewNumber where such numbers are internalized as
SMIs, and ensures that we still emit LdaSmi bytecodes for these values
in the generated bytecode.

BUG=v8:5203

Review-Url: https://codereview.chromium.org/2152853002
Cr-Commit-Position: refs/heads/master@{#37931}
      6b5949a8