1. 09 Jan, 2017 1 commit
  2. 06 Jan, 2017 1 commit
  3. 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
  4. 29 Dec, 2016 2 commits
  5. 22 Dec, 2016 1 commit
  6. 21 Dec, 2016 1 commit
  7. 20 Dec, 2016 1 commit
    • 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
  8. 16 Dec, 2016 2 commits
  9. 05 Dec, 2016 1 commit
  10. 01 Dec, 2016 2 commits
  11. 28 Nov, 2016 2 commits
  12. 25 Nov, 2016 2 commits
  13. 24 Nov, 2016 1 commit
  14. 22 Nov, 2016 1 commit
  15. 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
  16. 18 Nov, 2016 1 commit
  17. 10 Nov, 2016 1 commit
  18. 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
  19. 24 Oct, 2016 2 commits
  20. 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
  21. 18 Oct, 2016 2 commits
    • 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
    • bmeurer's avatar
      [ic] Unify CallIC feedback collection and handling. · 308788b3
      bmeurer authored
      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=mvstanton@chromium.org, mythria@chromium.org
      BUG=v8:2206,v8:4280,v8:5267
      
      Review-Url: https://codereview.chromium.org/2426693002
      Cr-Commit-Position: refs/heads/master@{#40397}
      308788b3
  22. 12 Oct, 2016 1 commit
  23. 11 Oct, 2016 1 commit
  24. 07 Oct, 2016 3 commits
  25. 06 Oct, 2016 1 commit
  26. 28 Sep, 2016 1 commit
  27. 26 Sep, 2016 2 commits
    • bmeurer's avatar
      Revert of [compiler] Properly guard the speculative optimizations for... · b9cdb630
      bmeurer authored
      Revert of [compiler] Properly guard the speculative optimizations for instanceof. (patchset #3 id:40001 of https://codereview.chromium.org/2370693002/ )
      
      Reason for revert:
      Tanks EarleyBoyer.
      
      Original issue's description:
      > [compiler] Properly guard the speculative optimizations for instanceof.
      >
      > Add a general feedback slot for instanceof similar to what we already have
      > for for-in, which basically has a fast (indicated by the uninitialized
      > sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
      > we can only take the fast path when the feedback slot says it hasn't
      > seen any funky inputs and nothing funky appeared in the prototype chain.
      > In the TurboFan code we also deoptimize whenever we see a funky object
      > (i.e. a proxy or an object that requires access checks) in the prototype
      > chain (similar to what Crankshaft already did).
      >
      > Drive-by-fix: Also make Crankshaft respect the mode and therefore
      > address the deopt loop in Crankshaft around instanceof.
      >
      > We might want to introduce an InstanceOfIC mechanism at some point and
      > track the map of the right-hand side.
      >
      > BUG=v8:5267
      > R=mvstanton@chromium.org
      >
      > Committed: https://crrev.com/a0484bc6116ebc2b855de87d862945e2ae07169b
      > Cr-Commit-Position: refs/heads/master@{#39718}
      
      TBR=mvstanton@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2365223003
      Cr-Commit-Position: refs/heads/master@{#39736}
      b9cdb630
    • bmeurer's avatar
      [compiler] Properly guard the speculative optimizations for instanceof. · a0484bc6
      bmeurer authored
      Add a general feedback slot for instanceof similar to what we already have
      for for-in, which basically has a fast (indicated by the uninitialized
      sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
      we can only take the fast path when the feedback slot says it hasn't
      seen any funky inputs and nothing funky appeared in the prototype chain.
      In the TurboFan code we also deoptimize whenever we see a funky object
      (i.e. a proxy or an object that requires access checks) in the prototype
      chain (similar to what Crankshaft already did).
      
      Drive-by-fix: Also make Crankshaft respect the mode and therefore
      address the deopt loop in Crankshaft around instanceof.
      
      We might want to introduce an InstanceOfIC mechanism at some point and
      track the map of the right-hand side.
      
      BUG=v8:5267
      R=mvstanton@chromium.org
      
      Review-Url: https://codereview.chromium.org/2370693002
      Cr-Commit-Position: refs/heads/master@{#39718}
      a0484bc6
  28. 24 Sep, 2016 1 commit
  29. 23 Sep, 2016 2 commits