1. 06 Jul, 2017 1 commit
  2. 26 Jun, 2017 2 commits
  3. 23 Jun, 2017 1 commit
  4. 21 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce new JSConstructWithArrayLike operator. · 21701297
      bmeurer authored
      Add a new JSConstructWithArrayLike operator that is backed by the
      ConstructWithArrayLike builtin (similar to what was done before
      for the JSCallWithArrayLike operator), and use that operator to
      optimize Reflect.construct inlining in TurboFan. This is handled
      uniformly with JSConstructWithSpread in the JSCallReducer.
      
      Also add missing test coverage for Reflect.construct in optimized
      code, especially for some interesting corner cases.
      
      R=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2949813002
      Cr-Commit-Position: refs/heads/master@{#46087}
      21701297
  5. 20 Jun, 2017 2 commits
    • bmeurer's avatar
      [turbofan] Introduce new JSCallWithArrayLike operator. · 767ce788
      bmeurer authored
      Add a new JSCallWithArrayLike operator that is backed by the
      CallWithArrayLike builtin, and use that operator for both
      Function.prototype.apply and Reflect.apply inlining. Also unify
      the handling of JSCallWithArrayLike and JSCallWithSpread in
      the JSCallReducer to reduce the copy&paste overhead.
      
      Drive-by-fix: Add a lot of test coverage for Reflect.apply and
      Function.prototype.apply in optimized code, especially for some
      corner cases, which was missing so far.
      
      BUG=v8:4587,v8:5269
      R=petermarshall@chromium.org
      
      Review-Url: https://codereview.chromium.org/2950773002
      Cr-Commit-Position: refs/heads/master@{#46041}
      767ce788
    • Peter Marshall's avatar
      [runtime] Port SpreadCall code to CSA. · a971a64d
      Peter Marshall authored
      We can remove a lot of native code and rely on CallOrConstructVarargs
      to do the stack manipulation for us.
      
      This will also take advantage of the fast-path for double arrays in
      CallOrConstructDoubleVarargs.
      
      We can also remove Runtime_SpreadIterableFixed because it isn't used
      anymore. We just call directly into spread_iterable from CSA.
      
      Bug: v8:6488, chromium:704966
      Change-Id: I81a18281f062619851134fff7ce88471566ee3b5
      Reviewed-on: https://chromium-review.googlesource.com/535615Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46038}
      a971a64d
  6. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback
      vector to store an optimization marker (optimize/in optimization queue)
      rather than changing the JSFunction's code object. Then, adapt the
      self-healing mechanism to also dispatch based on this optimization
      marker. Similarly, replace SFI marking with optimization marker checks
      in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing
      shared function marking) without leaking this information across native
      contexts. Non I+TF functions (asm.js or --no-turbo) use a
      CheckOptimizationMarker shim which generalises the old
      CompileOptimized/InOptimizationQueue builtins and also checks the same
      optimization marker as CompileLazy and InterpreterEntryTrampoline.
      
      This is a reland of https://chromium-review.googlesource.com/c/509716
      
      Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
      Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  7. 14 Jun, 2017 1 commit
  8. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored
      This reverts commit e39c9e02.
      
      Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
      
      Original change's description:
      > [compiler] Drive optimizations with feedback vector
      > 
      > For interpreted functions, use the optimized code slot in the feedback vector
      > to store an optimization marker (optimize/in optimization queue) rather than
      > changing the JSFunction's code object. Then, adapt the self-healing mechanism
      > to also dispatch based on this optimization marker. Similarly, replace SFI
      > marking with optimization marker checks in CompileLazy.
      > 
      > This allows JSFunctions to share optimization information (replacing shared
      > function marking) without leaking this information across native contexts. Non
      > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      > generalises the old CompileOptimized/InOptimizationQueue builtins and also
      > checks the same optimization marker as CompileLazy and
      > InterpreterEntryTrampoline.
      > 
      > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      > Reviewed-on: https://chromium-review.googlesource.com/509716
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45901}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      
      Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
      Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback vector
      to store an optimization marker (optimize/in optimization queue) rather than
      changing the JSFunction's code object. Then, adapt the self-healing mechanism
      to also dispatch based on this optimization marker. Similarly, replace SFI
      marking with optimization marker checks in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing shared
      function marking) without leaking this information across native contexts. Non
      I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      generalises the old CompileOptimized/InOptimizationQueue builtins and also
      checks the same optimization marker as CompileLazy and
      InterpreterEntryTrampoline.
      
      Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      Reviewed-on: https://chromium-review.googlesource.com/509716
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  9. 12 Jun, 2017 3 commits
  10. 09 Jun, 2017 1 commit
    • jgruber's avatar
      [debug] Untangle DebugInfo from break point support (mips,mips64) · d1ffd45e
      jgruber authored
      The mips/mips64 port of http://crrev.com/2909893002. Original commit message:
      
      DebugInfo was very closely tied to break point support:
      * It contained only information relevant to break points.
      * It was created and freed by break point implementation.
      * Existence of a DebugInfo on the shared function info implied existence of
        break points.
      
      This CL is a step towards making DebugInfo usable by other debugging
      functionality such as block coverage by decoupling it from break point support,
      which is now only one kind of information stored on the DebugInfo object.
      
      BUG=v8:6000
      
      Change-Id: Ia770ff3c048022652d8abbe30d372fde5cb452a4
      Reviewed-on: https://chromium-review.googlesource.com/528112Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45807}
      d1ffd45e
  11. 08 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Start refactoring the Apply builtin. · af76779a
      bmeurer authored
      This splits the monolithic Apply builtin into several smaller builtins,
      namely CallVargargs and ConstructVarargs, which accept a length and a
      FixedArray of elements and deal with the actual stack manipulation, and
      CallWithArrayLike / ConstructWithArrayLike that deal with getting the
      elements from the receiver (for Function.prototype.apply, Reflect.apply
      and Reflect.construct), which can now be written using the CSA.
      
      The idea is that these builtins can be reused by TurboFan directly in
      the future when we optimize apply better, and that we can also reuse the
      core logic in the handling of spread calls/constructs.
      
      R=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2930623002
      Cr-Commit-Position: refs/heads/master@{#45794}
      af76779a
  12. 07 Jun, 2017 1 commit
    • danno's avatar
      Inline Array.prototype.forEach in TurboFan · 90c3a2d5
      danno authored
      This CL contains a few pieces:
      
      - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
        graphs, which--when triggered--swizzle the values in the the FrameState to be
        parameters to a typically TF-generated builtin that resumes execution to finish
        the slow-case functionality.
      - Continuation builtins that have special handling in the deoptimizer and their own
        new frame type to ensure that the values they need to begin executing can be stashed
        away and restored immediately before the builtin is called via a trampoline that runs
        when the continuation builtin's frame execution resumes.
      - An implementation of Array.prototype.forEach in TurboFan that can be used to
        inline it. The inlined forEach implementation uses the checkpoints mechanism
        described above to deopt in the middle of the forEach in the cases that optimization
        invariants are violated. There is a slightly different continuation stub for each
        deopt point in the forEach implementation to ensure the correct side-effects, i.e.
        that the deopt of the builtin isn't programmatically observable.
      
      Review-Url: https://codereview.chromium.org/2803853005
      Cr-Commit-Position: refs/heads/master@{#45764}
      90c3a2d5
  13. 31 May, 2017 1 commit
    • jgruber's avatar
      [debug] Untangle DebugInfo from break point support · d3371c23
      jgruber authored
      DebugInfo was very closely tied to break point support:
      * It contained only information relevant to break points.
      * It was created and freed by break point implementation.
      * Existence of a DebugInfo on the shared function info implied existence of
        break points.
      
      This CL is a step towards making DebugInfo usable by other debugging
      functionality such as block coverage by decoupling it from break point support,
      which is now only one kind of information stored on the DebugInfo object.
      
      BUG=v8:6000
      
      Review-Url: https://codereview.chromium.org/2909893002
      Cr-Commit-Position: refs/heads/master@{#45640}
      d3371c23
  14. 23 May, 2017 2 commits
    • machenbach's avatar
      Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3... · 3d40a47a
      machenbach authored
      Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3 id:40001 of https://codereview.chromium.org/2900703002/ )
      
      Reason for revert:
      Speculative revert for:
      https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/8901
      
      Original issue's description:
      > [es2015] Precompute the descriptive string for symbols.
      >
      > Previously the String constructor and the Symbol.prototype.toString
      > methods had to compute the descriptive string for a Symbol on the fly,
      > which can produce a lot of garbage when this happens a lot, i.e. when
      > the String representation of a Symbol is used often. Now instead of
      > doing this on-demand we can just do it upfront when creating the Symbol.
      >
      > That way we also ensure that we won't throw an exception when accessing
      > the descriptive string of a Symbol, due to potential String length
      > overflow, but have the exception during Symbol creation upfront, which
      > is a lot less surprising behavior.
      >
      > BUG=v8:6278,v8:6344,v8:6350
      > TBR=mlippautz@chromium.org
      > R=ishell@chromium.org
      >
      > Review-Url: https://codereview.chromium.org/2900703002
      > Cr-Commit-Position: refs/heads/master@{#45479}
      > Committed: https://chromium.googlesource.com/v8/v8/+/e87573822e1c0c041c03f2b60599b0ab9256422f
      
      TBR=ishell@chromium.org,mlippautz@chromium.org,bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:6278,v8:6344,v8:6350
      
      Review-Url: https://codereview.chromium.org/2903533002
      Cr-Commit-Position: refs/heads/master@{#45483}
      3d40a47a
    • bmeurer's avatar
      [es2015] Precompute the descriptive string for symbols. · e8757382
      bmeurer authored
      Previously the String constructor and the Symbol.prototype.toString
      methods had to compute the descriptive string for a Symbol on the fly,
      which can produce a lot of garbage when this happens a lot, i.e. when
      the String representation of a Symbol is used often. Now instead of
      doing this on-demand we can just do it upfront when creating the Symbol.
      
      That way we also ensure that we won't throw an exception when accessing
      the descriptive string of a Symbol, due to potential String length
      overflow, but have the exception during Symbol creation upfront, which
      is a lot less surprising behavior.
      
      BUG=v8:6278,v8:6344,v8:6350
      TBR=mlippautz@chromium.org
      R=ishell@chromium.org
      
      Review-Url: https://codereview.chromium.org/2900703002
      Cr-Commit-Position: refs/heads/master@{#45479}
      e8757382
  15. 18 May, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Avoid allocating rest parameters for spread calls. · bfa319e5
      bmeurer authored
      We already had an optimization to turn Function.prototype.apply with
      arguments object, i.e.
      
        function foo() { return bar.apply(this, arguments); }
      
      into a special operator JSCallForwardVarargs, which avoids the
      allocation and deconstruction of the arguments object, but just passes
      along the incoming parameters. We can do the same for rest parameters
      and spread calls/constructs, i.e.
      
        class A extends B {
          constructor(...args) { super(...args); }
        }
      
      or
      
        function foo(...args) { return bar(1, 2, 3, ...args); }
      
      where we basically pass along the parameters (plus maybe additional
      statically known parameters).
      
      For this, we introduce a new JSConstructForwardVarargs operator and
      generalize the CallForwardVarargs builtins that are backing this.
      
      BUG=v8:6407,v8:6278,v8:6344
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2890023004
      Cr-Commit-Position: refs/heads/master@{#45388}
      bfa319e5
  16. 16 May, 2017 1 commit
  17. 15 May, 2017 1 commit
  18. 12 May, 2017 1 commit
  19. 11 May, 2017 1 commit
  20. 10 May, 2017 2 commits
  21. 08 May, 2017 2 commits
    • 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
    • Ross McIlroy's avatar
      Revert "[Interpreter] Transition JSFunctions to call optimized code when possible." · ce899dfd
      Ross McIlroy authored
      This reverts commit ec619cbd.
      
      Reason for revert: Crashing on Canary
      BUG=chromium:718891
      
      Original change's description:
      > [Interpreter] Transition JSFunctions to call optimized code when possible.
      > 
      > Now that the optimized code hangs off the feedback vector, it is possible
      > to check whether a function has optimized code available every time it's
      > called in the interpreter entry trampoline. If optimized code exists, the
      > interpreter entry trampoline 'self-heals' the closure to point to the
      > optimized code and links the closure into the optimized code list.
      > 
      > BUG=v8:6246
      > 
      > Change-Id: If1bd7c555bb0551bfe04b36baa6bcf949604717e
      > Reviewed-on: https://chromium-review.googlesource.com/488026
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45103}
      
      TBR=rmcilroy@chromium.org,mvstanton@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6246
      
      Change-Id: Ibda719be90fddf1d116c03a2a0c3018bcbe76018
      Reviewed-on: https://chromium-review.googlesource.com/498632Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45169}
      ce899dfd
  22. 04 May, 2017 2 commits
  23. 02 May, 2017 2 commits
  24. 20 Apr, 2017 2 commits
  25. 18 Apr, 2017 1 commit
  26. 12 Apr, 2017 1 commit
  27. 11 Apr, 2017 2 commits
  28. 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