Skip to content

V
V8
Switch branch/tag
  1. 30 Aug, 2016 6 commits
    • jgruber's avatar
      Fix LookupCode for the DatePrototype_GetField builtin · 4f781d72
      jgruber authored 
      This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.

This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
  instruction.
* Lookup itself is naive in that it just returns the first code object
  for which (next_code_obj_addr > pc). It does not check that pc is
  actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
  at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
  but with the wrong code object.

This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.

BUG=v8:5311

Review-Url: https://codereview.chromium.org/2284673002
Cr-Commit-Position: refs/heads/master@{#38996}
      4f781d72
    • v8-autoroll's avatar
      Update V8 DEPS. · 3b8a2e51
      v8-autoroll authored 
      Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f

Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5

Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3

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

Review-Url: https://codereview.chromium.org/2289063002
Cr-Commit-Position: refs/heads/master@{#38995}
      3b8a2e51
    • akos.palfi's avatar
      v8.gyp: Fix mips (big-endian) build. · cdab5ed6
      akos.palfi authored 
      Fixes the MIPS big-endian build after https://codereview.chromium.org/2276733002/ .

BUG=

Review-Url: https://codereview.chromium.org/2296473002
Cr-Commit-Position: refs/heads/master@{#38994}
      cdab5ed6
    • zhengxing.li's avatar
      X87: [Turbofan]: Use new MachineTypes in access-builder. · fdef4132
      zhengxing.li authored 
        port 56429fc1 (r38978)

  original commit message:
  Introduced MachineType::TaggedSigned() and TaggedPointer().

  The idea is to quit using the representational dimension of Type, and
  instead encode this information in the MachineRepresentation (itself
  lightly wrapped in MachineType, along with MachineSemantic).

  There are three parts to the whole change:

  1) Places that set the machine representation - constant nodes, loads nad
     stores, global object and native context specialization.

  2) Places that propagate type/representation - this is representation
     inference (aka simplified lowering). At the end of this process we
     expect to have a MachineRepresentation for every node. An interesting
     part of this is phi merging.

  3) Places that examine representation - WriteBarrier elimination does this.
     Currently it's looking at the Type representation dimension, but as
     a part of this change (or in a soon-to-follow change) it can simply
     examine the MachineRepresentation.

BUG=

Review-Url: https://codereview.chromium.org/2293603003
Cr-Commit-Position: refs/heads/master@{#38993}
      fdef4132
    • zhengxing.li's avatar
      X87: [turbofan] Remove special JSForInStep and JSForInDone. · 5572cea1
      zhengxing.li authored 
        port 1915762c (r38968)

  original commit message:
  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.

BUG=

Review-Url: https://codereview.chromium.org/2286353003
Cr-Commit-Position: refs/heads/master@{#38992}
      5572cea1
    • bmeurer's avatar
      [test] Speed-up regression test for growing stores. · 864cdc12
      bmeurer authored 
      TBR=machenbach@chromium.org
BUG=chromium:635798,chromium:638295

Review-Url: https://codereview.chromium.org/2288813003
Cr-Commit-Position: refs/heads/master@{#38991}
      864cdc12
  3. 29 Aug, 2016 28 commits
  5. 28 Aug, 2016 3 commits
  7. 27 Aug, 2016 2 commits
  9. 26 Aug, 2016 1 commit
    • littledan's avatar
      Desugar async/await to create the resulting Promise upfront · 5386c006
      littledan authored 
      As part of the work to implement catch prediction for async functions,
the resulting Promise that is the output of the function needs to be
available earlier for a couple reasons:
- To be able to do %DebugPushPromise/%DebugPopPromise over the body
  of the async function
- To be able to pass the resulting promise into AsyncFunctionAwait
  in order to set up the dependency chains

This patch creates the Promise earlier and pushes it onto the debug
stack; a later patch will set up the dependency chain. Although the
debug stack is set up, it's not anticipated that this will change
the catch prediction helpfully yet, as everything will still likely
be predicted as 'caught' for now, as before.

R=caitp@igalia.com,yangguo@chromium.org
CC=neis@chromium.org,gsathya@chromium.org
BUG=v8:5167

Review-Url: https://codereview.chromium.org/2233923003
Cr-Commit-Position: refs/heads/master@{#38957}
      5386c006