1. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored
      This change significantly improves the performance of string
      concatenation in optimized code for the case where the resulting string
      is represented as a ConsString. On the relevant test cases we go from
      
        serializeNaive: 10762 ms.
        serializeClever: 7813 ms.
        serializeConcat: 10271 ms.
      
      to
      
        serializeNaive: 10278 ms.
        serializeClever: 5533 ms.
        serializeConcat: 10310 ms.
      
      which represents a 30% improvement on the "clever" benchmark, which
      tests specifically the ConsString creation performance.
      
      This was accomplished via a couple of different steps, which are briefly
      outlined here:
      
        1. The empty_string gets its own map, so that we can easily recognize
           and handle it appropriately in the TurboFan type system. This
           allows us to express (and assert) that the inputs to NewConsString
           are non-empty strings, making sure that TurboFan no longer creates
           "crippled ConsStrings" with empty left or right hand sides.
        2. Further split the existing String types in TurboFan to be able to
           distinguish between OneByte and TwoByte strings on the type system
           level. This allows us to avoid having to dynamically lookup the
           resulting ConsString map in case of ConsString creation (i.e. when
           we know that both input strings are OneByte strings or at least
           one of the input strings is TwoByte).
        3. We also introduced more finegrained feedback for the Add bytecode
           in the interpreter, having it collect feedback about ConsStrings,
           specifically ConsOneByteString and ConsTwoByteString. This feedback
           can be used by TurboFan to only inline the relevant code for what
           was seen so far. This allows us to remove the Octane/Splay specific
           magic in JSTypedLowering to detect ConsString creation, and instead
           purely rely on the feedback of what was seen so far (also making it
           possible to change the semantics of NewConsString to be a low-level
           operator, which is only introduced in SimplifiedLowering by looking
           at the input types of StringConcat).
        4. On top of the before mentioned type and interpreter changes we added
           new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
           CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
           checks.
      
      There are several more improvements that are possible based on this, but
      since the change was already quite big, we decided not to put everything
      into the first change, but do some follow up tweaks to the type system,
      and builtin optimizations later.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:8834, v8:8931, v8:8939, v8:8951
      Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  2. 03 May, 2018 1 commit
  3. 19 Oct, 2017 1 commit
  4. 11 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Remove new.target from fixed frame slot. · c820b89b
      Ross McIlroy authored
      Removes the new.target slot from the interpreter's fixed frame. Instead
      adds a field to BytecodeArray to get the bytecode's incoming
      new.target or generator object register. The InterpreterEntryTrampoline
      then sets this register with the incoming new.target (or generator object)
      when the function is called. This register can be directly the new.target
      or generator object variable if they are LOCAL location, otherwise it is a
      temporary register which is then moved to the variable's location during the
      function prologue.
      
      This fixes a hack in the deoptimizer where we would set the new.target fixed
      slot to undefined in order to avoid extending it's lifetime through the
      optimized code - now it's just a standard register and can be optimized away
      as normal.
      
      Bug=v8:6644
      
      Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
      Reviewed-on: https://chromium-review.googlesource.com/608966
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47320}
      c820b89b
  5. 27 Jul, 2017 1 commit
  6. 25 Jul, 2017 1 commit
  7. 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
  8. 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
  9. 05 Jul, 2017 1 commit
  10. 22 Jun, 2017 1 commit
    • Daniel Ehrenberg's avatar
      [scopes] Fix sloppy-mode block-scoped function hoisting edge case · d54ffadf
      Daniel Ehrenberg authored
      In edge cases such as the following, sloppy-mode block-scoped function
      hoisting is expected to occur:
      
        eval(`
          with({a: 1}) {
            function a() {}
          }
        `)
      
      In this case, there should be the equivalent of a var declaration
      outside of the eval, which gets set to the value of the local function
      a when the body of the with is executed.
      
      Previously, the way that var declarations are hoisted out of eval
      meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
      assignment. However, such a lookup mode meant that the object in the
      with scope received the assignment!
      
      This patch fixes that error by marking the assignments produced by
      the sloppy mode block scoped function hoisting desugaring so as to
      generate a different runtime call which skips with scopes.
      
      Bug: chromium:720247, v8:5135
      Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
      Reviewed-on: https://chromium-review.googlesource.com/529230
      Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46116}
      d54ffadf
  11. 10 May, 2017 1 commit
  12. 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
  13. 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
  14. 02 May, 2017 2 commits
  15. 11 Apr, 2017 2 commits
  16. 10 Apr, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      Leszek Swirski authored
      Adds a collection of call bytecodes which have an implicit undefined
      receiver argument, for cases such as global calls where we know that the
      receiver has to be undefined. This way we can skip an LdaUndefined,
      decrease bytecode register pressure, and set a more accurate
      ConvertReceiverMode on the interpreter and TurboFan call.
      
      As a side effect, the "normal" Call bytecode now becomes a rare case
      (only with calls and super property calls), so we get rid of its 0-2
      argument special cases and modify CallProperty[N] to use the
      NotNullOrUndefined ConvertReceiverMode.
      
      Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
      Reviewed-on: https://chromium-review.googlesource.com/463287
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
  17. 09 Mar, 2017 1 commit
  18. 20 Feb, 2017 1 commit
  19. 17 Feb, 2017 1 commit
  20. 25 Jan, 2017 1 commit
  21. 14 Nov, 2016 1 commit
    • rmcilroy's avatar
      Only treat possible eval calls going through 'with' as special. · be9b820c
      rmcilroy authored
      This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL
      or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime
      call to find the callee and possibly update the receiver with the with-object.
      This means that eval calls out of 'with' blocks can now just do a normal
      LdaLookupGlobalSlot operation, which can check the context chain for eval
      extentions and fast-path the lookup if none exist.
      
      BUG=661556
      
      Review-Url: https://codereview.chromium.org/2487483004
      Cr-Commit-Position: refs/heads/master@{#40965}
      be9b820c
  22. 28 Oct, 2016 1 commit
  23. 18 Oct, 2016 1 commit
    • 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
  24. 04 Oct, 2016 1 commit
  25. 30 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. · 27fe988b
      rmcilroy authored
      There are only a few occasions where we allocate a register in an outer
      expression allocation scope, which makes the costly free-list approach
      of the BytecodeRegisterAllocator unecessary. This CL replaces all
      occurrences with moves to the accumulator and stores to a register
      allocated in the correct scope. By doing this, we can simplify the
      BytecodeRegisterAllocator to be a simple bump-pointer allocator
      with registers released in the same order as allocated.
      
      The following changes are also made:
       - Make BytecodeRegisterOptimizer able to use registers which have been
         unallocated, but not yet reused
       - Remove RegisterExpressionResultScope and rename
         AccumulatorExpressionResultScope to ValueExpressionResultScope
       - Introduce RegisterList to represent consecutive register
         allocations, and use this for operands to call bytecodes.
      
      By avoiding the free-list handling, this gives another couple of
      percent on CodeLoad.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2369873002
      Cr-Commit-Position: refs/heads/master@{#39905}
      27fe988b
  26. 20 Sep, 2016 1 commit
  27. 16 Sep, 2016 1 commit
  28. 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
  29. 07 Sep, 2016 1 commit
  30. 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
  31. 02 Sep, 2016 1 commit
  32. 01 Sep, 2016 1 commit
  33. 03 Aug, 2016 1 commit
  34. 27 May, 2016 1 commit
  35. 11 May, 2016 1 commit
  36. 18 Apr, 2016 1 commit
  37. 14 Apr, 2016 2 commits