Skip to content

V
V8
Switch branch/tag
  1. 09 Jan, 2017 2 commits
  3. 06 Jan, 2017 1 commit
  5. 05 Jan, 2017 1 commit
    • gsathya's avatar
      [ESnext] Implement Object spread · a40b7172
      gsathya authored 
      This patch adds parsing of spread object property.

-- Changes ParsePropertyName to parse Token::ELLIPSIS.
-- Throws if rest is encountered by setting a pattern error.
-- Adds a new PropertyKind enum (SPREAD)
-- Adds a new ObjectLiteralProperty::kind (SPREAD)
-- Adds a new harmony-object-spread flag and protects the parser code
with it.
-- Adds a new runtime function called CopyDataProperties
-- Does not add any support for this feature in fullcodegen.
-- Ignition calls out to a runtime function CopyDataProperties to
perform spread operation.
-- Move FastAssign from builtins-objects.cc to objects.cc
-- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties

Object rest will be implemented in a follow on patch.

BUG=v8:5549

Review-Url: https://codereview.chromium.org/2606833002
Cr-Commit-Position: refs/heads/master@{#42102}
      a40b7172
  7. 29 Dec, 2016 1 commit
  9. 22 Dec, 2016 1 commit
  11. 21 Dec, 2016 1 commit
  13. 20 Dec, 2016 2 commits
    • bjaideep's avatar
      PPC: Use a different map to distinguish eval contexts · cc48d2b1
      bjaideep authored 
      Port 53fdf9d1

Original Commit Message:

    eval() may introduce a scope which needs to be represented as a context at
    runtime, e.g.,

      eval('var x; let y; ()=>y')

    introduces a variable y which needs to have a context allocated for it. However,
    when traversing upwards to find the declaration context for a variable which leaks,
    as the declaration of x does above, this context has to be understood to not be
    a declaration context in sloppy mode.

    This patch makes that distinction by introducing a different map for eval-introduced
    contexts. A dynamic search for the appropriate context will continue past an eval
    context to find the appropriate context. Marking contexts as eval contexts rather
    than function contexts required updates in each compiler backend.

R=littledan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5295, chromium:648719
LOG=N

Review-Url: https://codereview.chromium.org/2590343002
Cr-Commit-Position: refs/heads/master@{#41872}
      cc48d2b1
    • littledan's avatar
      Use a different map to distinguish eval contexts · 53fdf9d1
      littledan authored 
      eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,

  eval('var x; let y; ()=>y')

introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.

This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.

BUG=v8:5295, chromium:648719

Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
      53fdf9d1
  15. 16 Dec, 2016 2 commits
  17. 05 Dec, 2016 1 commit
  19. 01 Dec, 2016 2 commits
  21. 28 Nov, 2016 2 commits
  23. 25 Nov, 2016 2 commits
  25. 24 Nov, 2016 1 commit
  27. 22 Nov, 2016 1 commit
  29. 21 Nov, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Remove deprecated generator implementation. · 09255541
      mstarzinger authored 
      This removes the deprecated generator support for resumable functions
from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
triggers Ignition for most resumable functions, with this change we make
said heuristic a hard choice and remove the deprecated code. This also
has the advantage that any suspended {JSGeneratorObject} instance on the
heap is guaranteed to have code based on a bytecode array.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2504223002
Cr-Commit-Position: refs/heads/master@{#41135}
      09255541
  31. 18 Nov, 2016 1 commit
  33. 14 Nov, 2016 1 commit
    • bjaideep's avatar
      PPC/s390: [turbofan] Remove special JSForInStep and JSForInDone. · b4ccb16a
      bjaideep authored 
      Port 1915762c

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.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2502503002
Cr-Commit-Position: refs/heads/master@{#40947}
      b4ccb16a
  35. 10 Nov, 2016 1 commit
  37. 02 Nov, 2016 1 commit
    • bmeurer's avatar
      [compiler] Sanitize IC counts for vector based ICs. · 5ef1bddf
      bmeurer authored 
      All vector ICs use the TypeFeedbackVector::ComputeCounts method now,
while the remaining patching ICs still use the traditional way of
counting on the TypeFeedbackInfo hanging off the fullcodegen code
object. This fixes the problem that counts were sometimes off.

Drive-by-fix: Move FullCodeGenerator::CallIC to fullcodegen.cc.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2472653002
Cr-Commit-Position: refs/heads/master@{#40690}
      5ef1bddf
  39. 24 Oct, 2016 2 commits
  41. 20 Oct, 2016 1 commit
    • adamk's avatar
      [ignition] Eliminate hole checks where statically possible for loads and stores · 35a3ccbf
      adamk authored 
      Move hole check logic from full-codegen into scope analysis, and store the
"needs hole check" bit on VariableProxy. This makes it easy to re-use in
any backend: it will be trivial to extend the use of this logic in, e.g.,
full-codegen variable stores.

While changing the signatures of the variable loading/storing methods in
Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these
are not part of AST visiting.

BUG=v8:5460

Review-Url: https://chromiumcodereview.appspot.com/2411873004
Cr-Commit-Position: refs/heads/master@{#40479}
      35a3ccbf
  43. 18 Oct, 2016 2 commits
    • bjaideep's avatar
      PPC/s390: [ic] Unify CallIC feedback collection and handling. · 78085e4d
      bjaideep authored 
      Port 308788b3

Original commit message:

    Consistently collect CallIC feedback in fullcodegen and Ignition, even
    for possibly direct eval calls, that were treated specially so far, for
    no apparent reason. With the upcoming SharedFunctionInfo based CallIC
    feedback, we might be able to even inline certain direct eval calls, if
    they manage to hit the eval cache. More importantly, this patch
    simplifies the collection and dealing with CallIC feedback (and as a
    side effect fixes an inconsistency with feedback for super constructor
    calls).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2425243003
Cr-Commit-Position: refs/heads/master@{#40412}
      78085e4d
    • bmeurer's avatar
      [intrinsics] Nuke %HasCachedArrayIndex and %GetCachedArrayIndex. · 6c85285b
      bmeurer authored 
      These intrinsics are unused now, and so we can drop all the code in
fullcodegen and Crankshaft that deals with those. TurboFan and Ignition
never tried to optimize those.

R=mstarzinger@chromium.org
BUG=v8:5049

Review-Url: https://codereview.chromium.org/2427673004
Cr-Commit-Position: refs/heads/master@{#40401}
      6c85285b
  45. 12 Oct, 2016 1 commit
    • bjaideep's avatar
      PPC/s390: [stubs] Refactor the CallICStub to pass the number of arguments. · c6f8955e
      bjaideep authored 
      Port c15c5827

Original commit message:

    This is the next step to unify the Call/Construct feedback collection
    and prepare it to be able to collect SharedFunctionInfo feedback. This
    also reduces the CallICStub overhead quite a bit since we only need one
    stub per mode (and tail call mode), not also one per call arity.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2415583002
Cr-Commit-Position: refs/heads/master@{#40228}
      c6f8955e
  47. 11 Oct, 2016 1 commit
  49. 07 Oct, 2016 3 commits
  51. 06 Oct, 2016 1 commit
  53. 28 Sep, 2016 1 commit
  55. 24 Sep, 2016 1 commit
  57. 23 Sep, 2016 2 commits