Skip to content

V
V8
Switch branch/tag
  1. 24 Jun, 2021 1 commit
  3. 24 Feb, 2021 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 Jan, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Rename type BailoutId to BytecodeOffset · 727d22be
      Jakob Gruber authored 
      This reflects the actual contents of the type, which is an offset into
the bytecode (or certain marker values). Historically, in the days of
FCG the bailout id used to refer to node ids - this is why certain
tracing output still calls the bailout id 'node id' and 'ast id'.
These spots will be fixed in a follow-up CL.

This change is mechanical:

 git grep -l BailoutId | while read f; do \
  sed -i 's/BailoutId/BytecodeOffset/g' $f; done

With a manual component of updating the DeoptimizationData method
name from 'BytecodeOffset' to 'GetBytecodeOffset'.

Bug: v8:11332
Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72189}
      727d22be
  11. 15 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboFan] Avoid serializing BytecodeAnalysis · 6544a1e4
      Ross McIlroy authored 
      The SerializerForBackgroundCompilation needs bytecode analysis for loop
target analysis, but doesn't require the much more expensive liveness
analysis. In order to move more work off the main thread, perform fast
bytecode analysis without liveness analysis in
SerializerForBackgroundCompilation, and then move the full bytecode
analysis to the background thread in BytecodeGraphBuilder.

BUG=v8:7790,v8:9684

Change-Id: I63ef80ecab8ad0c56953c72be31abc8f5a74b9c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593329Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71767}
      6544a1e4
  13. 10 Jul, 2020 1 commit
  15. 20 Mar, 2020 1 commit
  17. 29 Jul, 2019 1 commit
  19. 26 Jul, 2019 1 commit
  21. 15 Jul, 2019 1 commit
  23. 08 Jul, 2019 1 commit
  25. 19 Jun, 2019 1 commit
  27. 23 May, 2019 2 commits
  29. 29 Apr, 2019 1 commit
  31. 22 Jan, 2019 1 commit
  33. 18 Sep, 2018 1 commit
  35. 22 Mar, 2018 1 commit
  37. 27 Feb, 2018 1 commit
  39. 23 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [ignition] Single-switch generator bytecode · c869d40d
      Leszek Swirski authored 
      Currently, yields and awaits inside loops compile to bytecode which
switches to the top of the loop header, and switch again once inside the
loop. This is to make loops reducible.

This replaces this switching logic with a single switch bytecode that
directly jumps to the bytecode being resumed. Among other things, this
allows us to no longer maintain the generator state after the switch at
the top of the function, and avoid having to track loop suspend counts.

TurboFan still needs to have reducible loops, so we now insert loop
header switches during bytecode graph building, for suspends that are
discovered to be inside loops during bytecode analysis. We do, however,
do some environment magic across loop headers since we know that we will
continue switching if and only if we reached that loop header via a
generator resume. This allows us to generate fewer phis and tighten
liveness.

Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
Reviewed-on: https://chromium-review.googlesource.com/866734
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50804}
      c869d40d
  41. 22 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [compiler] Propagate liveness across suspends · 41b80eef
      Leszek Swirski authored 
      Suspend points (inside generators and async functions) have slightly
funky semantics when it comes to liveness, as they save and restore a
chunk of the register file as-is. In particular, this means that
granular liveness information is lost, as it is assumed that all
registers in that chunk of the register file are live in a suspend.

Rather than marking that entire chunk of register as live/dead in
suspend/restore, we can instead pattern-match the set of bytecodes in a
suspend point, and propagate liveness across them. This tightens
liveness estimates, and could be used to optimize which values TurboFan
actually saves when suspending.

Bug: chromium:798137
Change-Id: I5840cdbfc2c6edb1d3a48cf025f52615b629cdfc
Reviewed-on: https://chromium-review.googlesource.com/848895
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50757}
      41b80eef
  43. 05 Sep, 2017 1 commit
  45. 31 Aug, 2017 1 commit
  47. 25 Aug, 2017 1 commit
  49. 17 Aug, 2017 1 commit
    • Leszek Swirski's avatar
      [turbofan] Never generate loop exit phis for the accumulator · 1a302730
      Leszek Swirski authored 
      The accumulator should never be alive when jumping back to a loop
header, or jumping out of a loop. This means that as far as far as
TurboFan is concerned, we never need to create Phis or LoopExitValues
for the accumulator, as its value should not escape the loop.

For safety, this also augments the IsLivenessValid DCHECK in the
liveness analysis to check that the accumulator is not live in these
cases, and amends the bytecode analysis tests to kill the accumulator
where necessary to ensure this.

As a drive-by, added some comments to the more complex bytecode analysis
tests, since figuring out what they were for and how to fix them took a
non-trivial amount of time.

Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef
Reviewed-on: https://chromium-review.googlesource.com/615168
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47388}
      1a302730
  51. 16 Aug, 2017 1 commit
  53. 02 Aug, 2017 1 commit
  55. 02 Jun, 2017 1 commit
    • jarin's avatar
      This is a first step towards reducing the number of stores/loads when... · f0645612
      jarin authored 
      This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.

Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379

Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
      f0645612
  57. 15 May, 2017 1 commit
  59. 26 Apr, 2017 1 commit
  61. 25 Jan, 2017 1 commit
    • mstarzinger's avatar
      [turbofan] Fix accumulator use in bytecode analysis. · efc8cb16
      mstarzinger authored 
      This fixes the checks of accumulator usage flags in the computation of
the interpreter register liveness during bytecode analysis. The usage
flags at hand are bit patterns as opposed to flat enum values. Use the
safe accessors instead of plain comparison.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-683581
BUG=chromium:683581

Review-Url: https://codereview.chromium.org/2651653005
Cr-Commit-Position: refs/heads/master@{#42648}
      efc8cb16
  63. 15 Dec, 2016 1 commit
  65. 08 Dec, 2016 1 commit
  67. 05 Dec, 2016 1 commit
  69. 01 Dec, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Move OSR BailoutId translation into graph builder. · 8893d4ff
      mstarzinger authored 
      This moves the location of the bytecode-offset translation that turns
offsets of back jumps into offsets of loop headers. This translation is
now done by the {BytecodeGraphBuilder} after loop analysis has been
performed. It safes one redudant iteration over the bytecode array. Note
that this changes the semantics of the BailoutId used as an {osr_ast_id}
throughout the compiler pipeline for OSR from Ignition.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2465913002
Cr-Commit-Position: refs/heads/master@{#41431}
      8893d4ff
  71. 29 Nov, 2016 3 commits