Skip to content

V
V8
Switch branch/tag
  1. 11 Dec, 2015 7 commits
    • bmeurer's avatar
      [contexts] Place the initial JSArray maps on the native context directly. · 5964152c
      bmeurer authored 
      No need to have an indirection to get to the initial JSArray maps from
the native context; we only cache the fast elements maps anyway, so
those could live on the native context directly. This will also
integrate nicely with the load/store propagation in TurboFan (once we
propagate the immutable flag for FieldAccess as well).

Drive-by-fix: Also don't embed any of the initial JSArray maps in
TurboFan generated code when allocating a new JSArray, but instead
always load the appropriate map from the native context.  This way
we ensure that we never leak a reference to one of those maps and
its as efficient as embedding a constant map.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32779}
      5964152c
    • zhengxing.li's avatar
      X87: [turbofan] Make MachineType a pair of enums. · da7c5a73
      zhengxing.li authored 
        port bb2a830d (r32738)

  original commit message:
  MachineType is now a class with two enum fields:
  - MachineRepresentation
  - MachineSemantic

  Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
  - register allocator now uses just the representation.
  - Phi and Select nodes only refer to representations.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#32778}
      da7c5a73
    • adamk's avatar
      Rewrite Object.prototype.toString in C++ · ed698f3d
      adamk authored 
      The main impetus is to improve performance when --harmony-tostring
is enabled, thanks to using a generic property load instead of a
megamorphic IC.

This also reduces duplication, as the API function
v8::Object::ObjectProtoToString can share the runtime implementation.

The only functional change in this patch is to drop an accidental difference
between the JS and API implementations: the arguments object should toString
as "[object Arguments]". The JS side was corrected in
https://code.google.com/p/v8/source/detail?r=3279, but the API version was
missed in that patch.

BUG=chromium:555127, v8:3502
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

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

Cr-Commit-Position: refs/heads/master@{#32777}
      ed698f3d
    • v8-autoroll's avatar
      Update V8 DEPS. · 8bd39309
      v8-autoroll authored 
      Rolling v8/buildtools to 68e3c238a5ab347436762cb929316aa55ca72563

Rolling v8/tools/clang to 3a1510ccbc295798602abbbffcf61065704e8acb

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32776}
      8bd39309
    • mtrofin's avatar
      [turbofan] regalloc: model context and function mark as reg-defined. · 0b126143
      mtrofin authored 
      If we model them as memory operands ("SpillOperands"), as we
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free.

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack.
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame
construction, and let the register allocator spill them. That means they
need to be presented to the register allocator as vanilla live ranges,
with pre-assigned spill slots.

The main challenge there is that not all instructions (mainly, stack checks) list their dependency on these ranges being spilled. In this
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback
that we may see double spills in the case where these live ranges spill
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#32775}
      0b126143
    • adamk's avatar
      Revert of [es6] support AssignmentPattern as LHS in for-in/of loops (patchset... · 8b968b70
      adamk authored 
      Revert of [es6] support AssignmentPattern as LHS in for-in/of loops (patchset #9 id:280001 of https://codereview.chromium.org/1508933004/ )

Reason for revert:
Hits unreachable code (found by fuzzer). Example crasher:

"for(();;);"

Original issue's description:
> [es6] support AssignmentPattern as LHS in for-in/of loops
>
> BUG=v8:811, v8:4599
> LOG=N
> R=adamk@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/e47bdb775564b2cd8365047425898ab4274190a6
> Cr-Commit-Position: refs/heads/master@{#32773}

TBR=rossberg@chromium.org,caitpotter88@gmail.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811, v8:4599

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

Cr-Commit-Position: refs/heads/master@{#32774}
      8b968b70
    • caitpotter88's avatar
      [es6] support AssignmentPattern as LHS in for-in/of loops · e47bdb77
      caitpotter88 authored 
      BUG=v8:811, v8:4599
LOG=N
R=adamk@chromium.org, rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32773}
      e47bdb77
  3. 10 Dec, 2015 33 commits