Skip to content

V
V8
Switch branch/tag
  1. 26 Aug, 2015 7 commits
    • mtrofin's avatar
      [turbofan] Separate LiveRange and TopLevelLiveRange concepts · 0ee4b473
      mtrofin authored 
      A TopLevelLiveRange is the live range of a virtual register. Through
register allocation, it may end up being split in a succession of child
live ranges, where data flow is handled through moves from
predecessor to successor child.

Today, the concepts of "top level" and "child" live ranges are conflated
under the LiveRange class. However, a good few APIs pertain solely
to TopLevelLiveRanges. This was communicated through comments or
DCHECKs - but this makes for poor code comprehensibility and maintainability.

For example, the worklist of the register allocator (live_ranges()) needs
to only contain TopLevelLiveRanges; spill range concerns are associated
only with the top range; phi-ness; certain phases in the allocation pipeline;
APIs on LiveRange used for initial construction - before splitting;
splintering - these are all responsibilities associated to TopLevelLiveRanges,
and not child live ranges.

This change separates the concepts.

An effect of this change is that child live range allocation need not involve
RegisterAllocationData. That's "a good thing" (lower coupling), but it has
the side-effect of not having a good way to construct unique identifiers for
child live ranges, relative to a given InstructionSequence.

LiveRange Id are used primarily for tracing/output-ing, and debugging.

I propose a 2-component identifier: a virtual register (vreg) number,
uniquely identifying TopLevelLiveRanges; and a relative identifier, which
uniquely identifies children of a given TopLevelLiveRange. "0" is reserved
for the TopLevel range. The relative identifier does not necessarily
indicate order in the child chain, which is no worse than the current state
of affairs.

I believe this change should make it easier to understand a trace output
(because the virtual register number is readily available). I plan to formalize
with a small structure the notion of live range id, and consolidate tracing
around that, as part of a separate CL. (there are seemingly disparate ways
to trace - printf or stream-based APIs - so this seems like an opportune
change to consolidate that)

Review URL: https://codereview.chromium.org/1311983002

Cr-Commit-Position: refs/heads/master@{#30370}
      0ee4b473
    • v8-autoroll's avatar
      Update V8 DEPS. · 268420af
      v8-autoroll authored 
      Rolling v8/third_party/icu to 6b3ce817f8e828c3b7a577d2395f0882eb56ef18

TBR=machenbach@chromium.org

Review URL: https://codereview.chromium.org/1311613003

Cr-Commit-Position: refs/heads/master@{#30369}
      268420af
    • chunyang.dai's avatar
      X87: [Interpreter] Pass context to interpreter bytecode handlers and add LoadConstextSlot · b5911513
      chunyang.dai authored 
         For X87 platform, it has the same general register as ia32 and it will spill the
   context to the stack too.

port bfdc22d7 (r29325).

original commit message:

    Passes the current context to bytecode interpreter handlers. This is held in the
    context register on all architectures except for ia32 where there are too few
    registers and it is instead spilled to the stack.

    Also changes Load/StoreRegister to use kMachAnyTagged representation since they
    should only ever hold tagged values.

BUG=

Review URL: https://codereview.chromium.org/1316583003

Cr-Commit-Position: refs/heads/master@{#30368}
      b5911513
    • bradnelson's avatar
      Visit additional AST nodes as expressions in AstExpressionVisitor . · 457fc6bd
      bradnelson authored 
      Visit AST Property nodes as expressions in AstExpressionVisitor.
Visit Yield and Throw as they are expressions too.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-ast-expression-visitor, test-typing-reset
R=rossberg@chromium.org,titzer@chromium.org
LOG=N

Review URL: https://codereview.chromium.org/1314843002

Cr-Commit-Position: refs/heads/master@{#30367}
      457fc6bd
    • bbudge's avatar
      [simd.js] Clean up bad merge in messages.js · 48276d34
      bbudge authored 
      Eliminates duplicate var's and assignments.

LOG=N
BUG=v8:4124

Review URL: https://codereview.chromium.org/1315993002

Cr-Commit-Position: refs/heads/master@{#30366}
      48276d34
    • littledan's avatar
      Test262 roll to the 2015-8-25 version · 29ef63c6
      littledan authored 
      Review URL: https://codereview.chromium.org/1317723003

Cr-Commit-Position: refs/heads/master@{#30365}
      29ef63c6
    • littledan's avatar
      --harmony-sloppy-function depends on --harmony-sloppy · 88428816
      littledan authored 
      The lack of marking this dependency led to a ClusterFuzz crash when
sloppy-function was on but not sloppy. This case does not make sense.

R=adamk
LOG=N
BUG=chromium:520891

Review URL: https://codereview.chromium.org/1316773004

Cr-Commit-Position: refs/heads/master@{#30364}
      88428816
  3. 25 Aug, 2015 22 commits
  5. 24 Aug, 2015 11 commits