1. 06 Nov, 2017 1 commit
    • Toon Verwaest's avatar
      Drop custom accessor deoptimization support · c82cd313
      Toon Verwaest authored
      Previously StaNamedProperty and StaKeyedProperty were in a weird state where
      they claimed to not touch the accumulator, but actually did in case they were
      deopted in the middle. A frame was added in the middle to overwrite the 
      accumulator again with the right value before returning from the setter, using
      a lot of complexity in the deoptimizer.
      
      This changes those instructions to be marked as writing to the accumulator
      (e.g., the result of the setter), and uses to manually store and reload into
      the accumulator the value being stored.
      
      If we want to avoid the additional bytecodes, we could make sure that bytecodes
      that claim to leave the accumulator alone don't deopt back to Advance/Dispatch
      but LoadAccumulatorWithValue/Advance/Dispatch. That's in a way similar to what
      happened before this CL, but I believe could be implemented much simpler.
      
      
      Bug: 
      Change-Id: I4850a690ef5a30976701d0e050951faa46fd1c18
      Reviewed-on: https://chromium-review.googlesource.com/753487Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49159}
      c82cd313
  2. 19 Oct, 2017 1 commit
  3. 12 Oct, 2017 1 commit
  4. 12 Sep, 2017 1 commit
  5. 05 Sep, 2017 1 commit
  6. 27 Jul, 2017 1 commit
  7. 25 Jul, 2017 1 commit
  8. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored
      This reverts commit a2fcdc7c.
      
      Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
      
      Original change's description:
      > [runtime] Move profiler ticks from SFI to feedback vector
      > 
      > Instead of counting profiler ticks on the shared function info (which is
      > shared between native contexts), count them on the feedback vector
      > (which is not). This allows us to continue pushing optimization
      > decisions off the SFI, onto the feedback vector.
      > 
      > Note that a side-effect of this is that ICs don't have to walk the stack
      > to reset profiler ticks, as they can access the feedback vector directly
      > from their feedback nexus.
      > 
      > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
      > Reviewed-on: https://chromium-review.googlesource.com/544888
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46411}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
      Reviewed-on: https://chromium-review.googlesource.com/574227
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  9. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored
      Goal of this CL: explicit return from non-async function has position after
      return expression as return position (will unblock [1]).
      
      BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
      If one of these methods is called then next generated bytecode will get passed
      position. It's general treatment for most cases.
      Unfortunately it doesn't work for Returns:
      - debugger requires source positions exactly on kReturn bytecode in stepping
        implementation,
      - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
        generates more then one bytecode and general solution will put return position
        on first generated bytecode,
      - it's not easy to split BuildReturn function into two parts to allow something
        like following in BytecodeGenerator::VisitReturnStatement since generated
        bytecodes are actually controlled by execution_control().
      ..->BuildReturnPrologue();
      ..->SetReturnPosition(stmt);
      ..->Return();
      
      In this CL we pass ReturnStatement through ExecutionControl and use it for
      position when we emit return bytecode right here.
      
      So this CL only will improve return position for returns inside of non-async
      functions, I'll address async functions later.
      
      [1] https://chromium-review.googlesource.com/c/543161/
      
      Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
      Reviewed-on: https://chromium-review.googlesource.com/560738
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  10. 12 Jul, 2017 1 commit
  11. 05 Jul, 2017 1 commit
  12. 16 Jun, 2017 1 commit
  13. 29 May, 2017 1 commit
  14. 10 May, 2017 1 commit
  15. 08 May, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector" · fd749344
      Ross McIlroy authored
      This reverts commit 662aa425.
      
      Reason for revert: Crashing on Canary
      BUG=chromium:718891
      
      Original change's description:
      > Reland: [TypeFeedbackVector] Store optimized code in the vector
      > 
      > Since the feedback vector is itself a native context structure, why
      > not store optimized code for a function in there rather than in
      > a map from native context to code? This allows us to get rid of
      > the optimized code map in the SharedFunctionInfo, saving a pointer,
      > and making lookup of any optimized code quicker.
      > 
      > Original patch by Michael Stanton <mvstanton@chromium.org>
      > 
      > BUG=v8:6246
      > TBR=yangguo@chromium.org,ulan@chromium.org
      > 
      > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      > Reviewed-on: https://chromium-review.googlesource.com/494487
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45084}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6246
      
      Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
      Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45174}
      fd749344
  16. 04 May, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [TypeFeedbackVector] Store optimized code in the vector · 662aa425
      Ross McIlroy authored
      Since the feedback vector is itself a native context structure, why
      not store optimized code for a function in there rather than in
      a map from native context to code? This allows us to get rid of
      the optimized code map in the SharedFunctionInfo, saving a pointer,
      and making lookup of any optimized code quicker.
      
      Original patch by Michael Stanton <mvstanton@chromium.org>
      
      BUG=v8:6246
      TBR=yangguo@chromium.org,ulan@chromium.org
      
      Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45084}
      662aa425
  17. 03 May, 2017 1 commit
  18. 02 May, 2017 2 commits
  19. 27 Apr, 2017 1 commit
    • cbruni's avatar
      [runtime] Ensure slow properties for simple {__proto__:null} literals. · 3f73fecb
      cbruni authored
      With this CL we reduce the difference between directly using a null prototype
      in a literal or using Object.create(null).
      - The EmitFastCloneShallowObject builtin now supports cloning slow
        object boilerplates.
      - Unified behavior to find the matching Map and instantiating it for
        Object.create(null) and literals with a null prototype.
      - Cleanup of literal type parameter of CompileTimeValue, now in sync with
        ObjectLiteral flags.
      
      Review-Url: https://codereview.chromium.org/2445333002
      Cr-Commit-Position: refs/heads/master@{#44941}
      3f73fecb
  20. 18 Apr, 2017 1 commit
  21. 06 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Collect and use type feedback on ToNumber. · dd7ce93c
      bmeurer authored
      Make Ignition collect BinaryOperationFeedback on ToNumber, using the
      shared type feedback slot with the following Inc/Dec bytecode, and use
      this feedback in TurboFan to turn the ToNumber(x) operation into a
      SpeculativeNumberMultiply(x,1) with the feedback hint.
      
      R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
      BUG=v8:6214,v8:5267
      
      Review-Url: https://codereview.chromium.org/2804813003
      Cr-Commit-Position: refs/heads/master@{#44440}
      dd7ce93c
  22. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored
      They have the same lifetime. It's a match!
      
      Both structures are native context dependent and dealt with (creation,
      clearing, gathering feedback) at the same time. By treating the spaces used
      for literal boilerplates as feedback vector slots, we no longer have to keep
      track of the materialized literal count elsewhere.
      
      A follow-on CL removes even more parser infrastructure related to this count.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2655853010
      Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  23. 25 Jan, 2017 1 commit
  24. 09 Jan, 2017 1 commit
  25. 22 Dec, 2016 1 commit
  26. 21 Dec, 2016 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root literal arrays in function literals slots · 93df0940
      mvstanton authored
      Literal arrays and feedback vectors for a function can be garbage
      collected if we don't have a rooted closure for the function, which
      happens often. It's expensive to come back from this (recreating
      boilerplates and gathering feedback again), and the cost is
      disproportionate if the function was inlined into optimized code.
      
      To guard against losing these arrays when we need them, we'll now
      create literal arrays when creating the feedback vector for the outer
      closure, and root them strongly in that vector.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2504153002
      Cr-Commit-Position: refs/heads/master@{#41893}
      93df0940
  27. 16 Dec, 2016 1 commit
    • mstarzinger's avatar
      Introduce {ConstantElementsPair} struct for type safety. · 92b370ee
      mstarzinger authored
      This introduces an explicit struct for the communication channel between
      the {ArrayLiteral} AST node and the corresponding runtime methods. Those
      methods take a pair of {ElementsKind} as well as an array (can either be
      a FixedArray or a FixedDoubleArray) of constant values.
      
      For bonus points it also reduces the size of the involved heap object by
      one word (i.e. length field of FixedArray not needed anymore).
      
      R=mvstanton@chromium.org
      
      Review-Url: https://codereview.chromium.org/2581683003
      Cr-Commit-Position: refs/heads/master@{#41752}
      92b370ee
  28. 08 Nov, 2016 1 commit
  29. 28 Oct, 2016 1 commit
  30. 04 Oct, 2016 1 commit
  31. 20 Sep, 2016 1 commit
  32. 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
  33. 13 Sep, 2016 1 commit
    • leszeks's avatar
      [Interpreter] Move context chain search loop to handler · 1c0c5fda
      leszeks authored
      Moves the context chain search loop out of generated bytecode, and into
      the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
      an additional operand. This should decrease the bytecode size and
      increase performance for deep context chain searches, at the cost of
      slightly increasing bytecode size for shallow context access.
      
      Review-Url: https://codereview.chromium.org/2336643002
      Cr-Commit-Position: refs/heads/master@{#39378}
      1c0c5fda
  34. 07 Sep, 2016 1 commit
  35. 06 Sep, 2016 1 commit
    • leszeks's avatar
      [Interpreter] Remove constant pool type in tests · b28b7e13
      leszeks authored
      For historical reasons, the interpreter's bytecode expectations tests
      required a type for the constant pool. This had two disadvantages:
      
       1. Strings and numbers were not visible in mixed pools, and
       2. Mismatches of pool types (e.g. when rebaselining) would cause parser
          errors
      
      This removes the pool types, making everything 'mixed', but appending
      the values to string and number valued constants. Specifying a pool type
      in the *.golden header now prints a warning (for backwards compatibility).
      
      BUG=v8:5350
      
      Review-Url: https://codereview.chromium.org/2310103002
      Cr-Commit-Position: refs/heads/master@{#39216}
      b28b7e13
  36. 09 Aug, 2016 1 commit
  37. 08 Aug, 2016 1 commit
  38. 03 Aug, 2016 1 commit
  39. 22 Jul, 2016 1 commit