Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 27 Sep, 2016 1 commit
  5. 22 Sep, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. · e5ac75c6
      rmcilroy authored 
      This CL optimizes the code in BytecodeArrayBuilder and
BytecodeArrayWriter by making the following main changes:

 - Move operand scale calculation out of BytecodeArrayWriter to the
BytecodeNode constructor, where the decision on which operands are
scalable can generally be statically decided by the compiler.
 - Move the maximum register calculation out of BytecodeArrayWriter
and into BytecodeRegisterOptimizer (which is the only place outside
BytecodeGenerator which updates which registers are used). This
avoids the BytecodeArrayWriter needing to know the operand types
of a node as it writes it.
 - Modify EmitBytecodes to use individual push_backs rather than
building a buffer and calling insert, since this turns out to be faster.
 - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
bytes,
 - Make common functions in Bytecodes constexpr so that they
can be statically calculated by the compiler.
 - Move common functions and constructors in Bytecodes and
BytecodeNode to the header so that they can be inlined.
 - Change large static switch statements in Bytecodes to const array
lookups, and move to the header to allow inlining.

I also took the opportunity to remove a number of unused helper
functions, and rework some others for consistency.

This reduces the percentage of time spent in making BytecodeArrays
 in  CodeLoad from ~15% to ~11% according to perf. The
CoadLoad score increase by around 2%.

BUG=v8:4280

Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
Review-Url: https://codereview.chromium.org/2351763002
Cr-Original-Commit-Position: refs/heads/master@{#39599}
Cr-Commit-Position: refs/heads/master@{#39637}
      e5ac75c6
    • hablich's avatar
      Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.... · 5d693348
      hablich authored 
      Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. (patchset #6 id:200001 of https://codereview.chromium.org/2351763002/ )

Reason for revert:
Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/

Original issue's description:
> [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.
>
> This CL optimizes the code in BytecodeArrayBuilder and
> BytecodeArrayWriter by making the following main changes:
>
>  - Move operand scale calculation out of BytecodeArrayWriter to the
> BytecodeNode constructor, where the decision on which operands are
> scalable can generally be statically decided by the compiler.
>  - Move the maximum register calculation out of BytecodeArrayWriter
> and into BytecodeRegisterOptimizer (which is the only place outside
> BytecodeGenerator which updates which registers are used). This
> avoids the BytecodeArrayWriter needing to know the operand types
> of a node as it writes it.
>  - Modify EmitBytecodes to use individual push_backs rather than
> building a buffer and calling insert, since this turns out to be faster.
>  - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
> bytes,
>  - Make common functions in Bytecodes constexpr so that they
> can be statically calculated by the compiler.
>  - Move common functions and constructors in Bytecodes and
> BytecodeNode to the header so that they can be inlined.
>  - Change large static switch statements in Bytecodes to const array
> lookups, and move to the header to allow inlining.
>
> I also took the opportunity to remove a number of unused helper
> functions, and rework some others for consistency.
>
> This reduces the percentage of time spent in making BytecodeArrays
>  in  CodeLoad from ~15% to ~11% according to perf. The
> CoadLoad score increase by around 2%.
>
> BUG=v8:4280
>
> Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
> Cr-Commit-Position: refs/heads/master@{#39599}

TBR=mythria@chromium.org,leszeks@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280

Review-Url: https://codereview.chromium.org/2360193003
Cr-Commit-Position: refs/heads/master@{#39612}
      5d693348
  7. 21 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. · b11a8b4d
      rmcilroy authored 
      This CL optimizes the code in BytecodeArrayBuilder and
BytecodeArrayWriter by making the following main changes:

 - Move operand scale calculation out of BytecodeArrayWriter to the
BytecodeNode constructor, where the decision on which operands are
scalable can generally be statically decided by the compiler.
 - Move the maximum register calculation out of BytecodeArrayWriter
and into BytecodeRegisterOptimizer (which is the only place outside
BytecodeGenerator which updates which registers are used). This
avoids the BytecodeArrayWriter needing to know the operand types
of a node as it writes it.
 - Modify EmitBytecodes to use individual push_backs rather than
building a buffer and calling insert, since this turns out to be faster.
 - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
bytes,
 - Make common functions in Bytecodes constexpr so that they
can be statically calculated by the compiler.
 - Move common functions and constructors in Bytecodes and
BytecodeNode to the header so that they can be inlined.
 - Change large static switch statements in Bytecodes to const array
lookups, and move to the header to allow inlining.

I also took the opportunity to remove a number of unused helper
functions, and rework some others for consistency.

This reduces the percentage of time spent in making BytecodeArrays
 in  CodeLoad from ~15% to ~11% according to perf. The
CoadLoad score increase by around 2%.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2351763002
Cr-Commit-Position: refs/heads/master@{#39599}
      b11a8b4d
  9. 20 Sep, 2016 1 commit
  11. 16 Sep, 2016 1 commit
  13. 13 Sep, 2016 3 commits
  15. 06 Sep, 2016 1 commit
  17. 05 Sep, 2016 1 commit
    • jochen's avatar
      Store the scope info in catch contexts · 9b6ff3a8
      jochen authored 
      Since the extension field is already used for the catch name, store a
ContextExtension there instead.

In the future, this will allow for chaining ScopeInfos together, so we
no longer need a context chain for lazy parsing / compilation.

BUG=v8:5215
R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org

Review-Url: https://codereview.chromium.org/2302013002
Cr-Commit-Position: refs/heads/master@{#39164}
      9b6ff3a8
  19. 02 Sep, 2016 2 commits
  21. 30 Aug, 2016 1 commit
  23. 29 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove special JSForInStep and JSForInDone. · 1915762c
      bmeurer authored 
      These JavaScript operators were special hacks to ensure that we always
operate on Smis for the magic for-in index variable, but this never
really worked in the OSR case, because the OsrValue for the index
variable didn't have the proper information (that we have for the
JSForInPrepare in the non-OSR case).

Now that we have loop induction variable analysis and binary operation
hints, we can just use JSLessThan and JSAdd instead with appropriate
Smi hints, which handle the OSR case by inserting Smi checks (that are
always true). Thanks to OSR deconstruction and loop peeling these Smi
checks will be hoisted so they don't hurt the OSR case too much.

Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
we have to lower it to JSLessThan to get the loop induction variable
goodness.

R=epertoso@chromium.org
BUG=v8:5267

Review-Url: https://codereview.chromium.org/2289613002
Cr-Commit-Position: refs/heads/master@{#38968}
      1915762c
  25. 23 Aug, 2016 1 commit
  27. 18 Aug, 2016 3 commits
  29. 17 Aug, 2016 1 commit
    • rmcilroy's avatar
      Avoid accessing Isolate in source position logging. · b8b4a443
      rmcilroy authored 
      Now that all backends use the source position builder to record source
positions, simplify the code line logging events to take a source
position table on code creation. This means that the source position
table builder no longer needs to access the isolate until the table is
generated. This is required for off-thread bytecode generation.

BUG=v8:5203

Review-Url: https://codereview.chromium.org/2248673002
Cr-Commit-Position: refs/heads/master@{#38676}
      b8b4a443
  31. 16 Aug, 2016 1 commit
  33. 12 Aug, 2016 1 commit
  35. 11 Aug, 2016 1 commit
  37. 10 Aug, 2016 1 commit
  39. 09 Aug, 2016 1 commit
  41. 08 Aug, 2016 1 commit
  43. 05 Aug, 2016 3 commits
  45. 03 Aug, 2016 2 commits
  47. 29 Jul, 2016 1 commit
  49. 26 Jul, 2016 4 commits
  51. 25 Jul, 2016 2 commits
  53. 22 Jul, 2016 1 commit