1. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored
      This is a reland of cf93071c
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  2. 16 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored
      This reverts commit cf93071c.
      
      Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      
      This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      that we can use a single byte to represent the common operation of
      storing to a low-numbered register. This generally reduces the quantity
      of bytecode generated on web sites by 8-9%.
      
      In order to not degrade speed, a couple of other changes are required:
      
      The existing lookahead logic to check for Star after certain other
      bytecode handlers is updated to check for these new short Star codes
      instead. Furthermore, that lookahead logic is updated to contain its own
      copy of the dispatch jump rather than merging control flow with the
      lookahead-failed case, to improve branch prediction.
      
      A bunch of constants use bytecode size in bytes as a proxy for the size
      or complexity of a function, and are adjusted downward proportionally to
      the decrease in generated bytecode size.
      
      Other small drive-by fix: update generate-bytecode-expectations to emit
      \n instead of \r\n on Windows.
      
      Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
  3. 10 Feb, 2020 1 commit
  4. 12 Mar, 2018 1 commit
  5. 07 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. 10 May, 2017 1 commit
  13. 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
  14. 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
  15. 02 May, 2017 2 commits
  16. 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
  17. 18 Apr, 2017 1 commit
  18. 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
  19. 25 Jan, 2017 1 commit
  20. 21 Dec, 2016 1 commit
    • caitp's avatar
      [cctest] print name instead of context index for CallJSRuntime · 3d6a477b
      caitp authored
      Change bytecode-expectations-printer.cc in the cctest application so
      that intrinsic function names are printed rather than their native
      context index.
      
      This minimizes the amount of unnecessary changes to the bytecode
      expectations that need to happen whenever the context fields are
      changed.
      
      BUG=v8:5769
      R=neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org
      
      Review-Url: https://codereview.chromium.org/2593823002
      Cr-Commit-Position: refs/heads/master@{#41900}
      3d6a477b
  21. 19 Dec, 2016 1 commit
  22. 16 Dec, 2016 2 commits
  23. 08 Dec, 2016 3 commits
  24. 07 Dec, 2016 2 commits
  25. 15 Nov, 2016 1 commit
    • petermarshall's avatar
      Fastpath some spread-call desugaring. · a63eeb48
      petermarshall authored
      Avoid using the iterator for arrays with fast elements where the iterator has
      not been modified.
      
      Only deals with the case where there is a single spread argument.
      
      Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.
      
      BUG=v8:5511
      
      Review-Url: https://codereview.chromium.org/2465253011
      Cr-Commit-Position: refs/heads/master@{#40998}
      a63eeb48
  26. 10 Nov, 2016 2 commits
    • gsathya's avatar
      [promises] Move CreateResolvingFunctions to c++ · cb6c8e48
      gsathya authored
      - A new runtime function (%create_resolving_functions) is installed to
        call the CreateResolvingFunctions builtin from JS.
      
      - Three new builtins are created - resolve and reject functions and a
        third function that creates a new JSFunctions from these
        resolve/reject builtins.
      
      - The promise reject function is installed on the context temporarily
        as internal_promise_reject. This should go away once we remove
        PromiseSet.
      
      BUG=v8:5343
      
      Review-Url: https://codereview.chromium.org/2459283004
      Cr-Commit-Position: refs/heads/master@{#40903}
      cb6c8e48
    • rmcilroy's avatar
      [Interpreter] Remove all Ldr style bytecodes and replace with Star lookahead. · f633218b
      rmcilroy authored
      We seem to get some small wins from avoiding the Ldr bytecodes, probably due
      to reduced icache pressure since there are less bytecode handlers. Replace
      the Ldr bytecodes with Star lookahead inlined into the Lda versions.
      
      Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and
      LdaCurrentContextSlot
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2489513005
      Cr-Commit-Position: refs/heads/master@{#40883}
      f633218b
  27. 14 Oct, 2016 1 commit
    • jgruber's avatar
      [regexp] Turn last match info into a simple FixedArray · f60a7c4f
      jgruber authored
      Now that all accesses to the last match info are in C++ and TF code, we can
      finally turn the last match info into a FixedArray. Similar to the ArrayList,
      it uses its first field to store its length and grows dynamically in amortized
      O(1) time.
      
      Unlike previously, this means that the last match info pointer stored on the
      context can actually change (in case the FixedArray needs to grow).
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2415103002
      Cr-Commit-Position: refs/heads/master@{#40308}
      f60a7c4f
  28. 13 Oct, 2016 3 commits
    • jgruber's avatar
      [regexp] Port remaining JS functions in regexp.js · a10b4712
      jgruber authored
      This ports RegExpInitialize, IsRegExp, InternalMatch and InternalReplace to C++
      / TurboFan. InternalMatch is in TurboFan because it calls RegExpExecStub and
      needs to construct a RegExpResult (which are, respectively, a PlatformStub and
      a CodeStubAssembler function).
      
      Except for LastMatchInfo (and GetSubstitution, which could be moved to string.js
      anytime), regexp.js is now completely empty.
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2409513003
      Cr-Commit-Position: refs/heads/master@{#40277}
      a10b4712
    • neis's avatar
      [modules] Implement @@iterator on namespace objects. · dafe6867
      neis authored
      As part of this, introduce a new JSObject for iterating over the elements of a
      FixedArray.
      
      R=adamk@chromium.org,bmeurer@chromium.org
      TBR=ulan@chromium.org
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2407423002
      Cr-Commit-Position: refs/heads/master@{#40265}
      dafe6867
    • jgruber's avatar
      [regexp] Port RegExp.prototype[@@replace] · 33a4faa4
      jgruber authored
      This moves the implementation of @@replace from regexp.js to builtins-regexp.cc
      (the TurboFan fast path) and runtime-regexp.cc (slow path). The fast path
      handles all cases in which the regexp itself is an unmodified JSRegExp
      instance, the given 'replace' argument is not callable and does not contain any
      '$' characters (i.e. we are doing a string replacement).
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2398423002
      Cr-Commit-Position: refs/heads/master@{#40253}
      33a4faa4
  29. 11 Oct, 2016 1 commit
  30. 10 Oct, 2016 1 commit
  31. 07 Oct, 2016 1 commit