1. 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
  2. 16 Dec, 2016 2 commits
  3. 05 Dec, 2016 1 commit
  4. 01 Dec, 2016 2 commits
  5. 28 Nov, 2016 2 commits
  6. 25 Nov, 2016 2 commits
  7. 24 Nov, 2016 1 commit
  8. 22 Nov, 2016 1 commit
  9. 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
  10. 18 Nov, 2016 1 commit
  11. 10 Nov, 2016 1 commit
  12. 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
  13. 24 Oct, 2016 2 commits
  14. 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
  15. 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
  16. 12 Oct, 2016 1 commit
  17. 11 Oct, 2016 1 commit
  18. 07 Oct, 2016 3 commits
  19. 06 Oct, 2016 1 commit
  20. 28 Sep, 2016 1 commit
  21. 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
  22. 24 Sep, 2016 1 commit
  23. 23 Sep, 2016 3 commits
  24. 20 Sep, 2016 1 commit
  25. 16 Sep, 2016 1 commit
  26. 14 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Collect invocation counts and compute relative call frequencies. · c7d7ca36
      bmeurer authored
      Add a notion of "invocation count" to the baseline compilers, which
      increment a special slot in the TypeFeedbackVector for each invocation
      of a given function (the optimized code doesn't currently collect this
      information).
      
      Use this invocation count to relativize the call counts on the call
      sites within the function, so that the inlining heuristic has a view
      of relative importance of a call site rather than some absolute numbers
      with unclear meaning for the current function. Also apply the call site
      frequency as a factor to all frequencies in the inlinee by passing this
      to the graph builders so that the importance of a call site in an
      inlinee is relative to the topmost optimized function.
      
      Note that all functions that neither have literals nor need type
      feedback slots will share a single invocation count cell in the
      canonical empty type feedback vector, so their invocation count is
      meaningless, but that doesn't matter since we only use the invocation
      count to relativize call counts within the function, which we only have
      if we have at least one type feedback vector (the CallIC slot).
      
      See the design document for additional details on this change:
      https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
      
      BUG=v8:5267,v8:5372
      R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2337123003
      Cr-Commit-Position: refs/heads/master@{#39410}
      c7d7ca36
  27. 09 Sep, 2016 1 commit
  28. 06 Sep, 2016 1 commit
    • bakkot's avatar
      Split the AST representation of class properties from object properties. · 7bc200c7
      bakkot authored
      This introduces ClassLiteralProperty and a supertype LiteralProperty of
      it and ObjectLiteralProperty. It also splits the parsing of the two.
      This substiantially clarifies some logic, especially as classes
      continue to evolve, and is also about a 2% performance improvement to
      parsing either kind of property (since no work is wasted on logic
      only necessary for the other kind). Also, it saves a word on
      ObjectLiteralProperties.
      
      Review-Url: https://codereview.chromium.org/2302643002
      Cr-Commit-Position: refs/heads/master@{#39219}
      7bc200c7
  29. 05 Sep, 2016 1 commit