1. 21 Jun, 2017 2 commits
    • Ross McIlroy's avatar
      [TurboFan] Enable typed lowering of JSStringConcat to ConsString allocation. · 69a645d3
      Ross McIlroy authored
      Adds typed lowering of JSStringConcat to ConsString allocation if the
      following conditions hold:
       - All concatinations will result in a ConsString of >= ConString::kMinLength
       - No concatinations will result in a empty string in the RHS unless there is
         a sequential string in the LHS.
      
      This also means JSStringConcat needs an eager checkpoint since it can
      deopt if throwing a RangeError when the string length protector is valid.
      
      BUG=v8:6243
      
      Change-Id: I01ca79f884df467c10f2c032c72d51b5199c1a3c
      Reviewed-on: https://chromium-review.googlesource.com/526636
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46093}
      69a645d3
    • 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
  2. 20 Jun, 2017 1 commit
    • 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
  3. 13 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Properly optimize Object.prototype.isPrototypeOf. · b11c557d
      bmeurer authored
      Port the baseline implementation of Object.prototype.isPrototypeOf to
      the CodeStubAssembler, sharing the existing prototype chain lookup logic
      with the instanceof / OrdinaryHasInstance implementation. Based on that,
      do the same in TurboFan, introducing a new JSHasInPrototypeChain
      operator, which encapsulates the central prototype chain walk logic.
      
      This speeds up Object.prototype.isPrototypeOf by more than a factor of
      four, so that the code
      
        A.prototype.isPrototypeOf(a)
      
      is now performance-wise on par with
      
        a instanceof A
      
      for the case where A is a regular constructor function and a is an
      instance of A.
      
      Since instanceof does more than just the fundamental prototype chain
      lookup, it was discovered in Node core that O.p.isPrototypeOf would
      be a more appropriate alternative for certain sanity checks, since
      it's less vulnerable to monkey-patching. In addition, the Object
      builtin would also avoid the performance-cliff associated with
      instanceof (due to the Symbol.hasInstance hook), as for example hit
      by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
      The main blocker was the missing performance of isPrototypeOf, since
      it was still a JS builtin backed by a runtime call.
      
      This CL also adds more test coverage for the
      Object.prototype.isPrototypeOf builtin, especially when called from
      optimized code.
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      BUG=v8:5269,v8:5989,v8:6483
      R=jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2934893002
      Cr-Commit-Position: refs/heads/master@{#45925}
      b11c557d
  4. 07 Jun, 2017 1 commit
  5. 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
  6. 08 May, 2017 1 commit
  7. 07 Mar, 2017 1 commit
  8. 03 Mar, 2017 1 commit
  9. 17 Feb, 2017 1 commit
  10. 02 Feb, 2017 1 commit
  11. 01 Feb, 2017 2 commits
  12. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored
      Previously, when restarting a frame, we would rewrite all frames
      between the debugger activation and the frame to restart to squash
      them, and replace the return address with that of a builtin to
      leave that rewritten frame, and restart the function by calling it.
      
      We now simply remember the frame to drop to, and upon returning
      from the debugger, we check whether to drop the frame, load the
      new FP, and restart the function.
      
      R=jgruber@chromium.org, mstarzinger@chromium.org
      BUG=v8:5587
      
      Review-Url: https://codereview.chromium.org/2636913002
      Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  13. 26 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce JSCallForwardVarargs operator. · 69747e26
      bmeurer authored
      We turn a JSCallFunction node for
      
        f.apply(receiver, arguments)
      
      into a JSCallForwardVarargs node, when the arguments refers to the
      arguments of the outermost optimized code object, i.e. not an inlined
      arguments, and the apply method refers to Function.prototype.apply,
      and there's no other user of arguments except in frame states.
      
      We also replace the arguments node in the graph with a marker for
      the Deoptimizer similar to Crankshaft to make sure we don't materialize
      unused arguments just for the sake of deoptimization. We plan to replace
      this with a saner EscapeAnalysis based solution soon.
      
      R=jarin@chromium.org
      BUG=v8:5267,v8:5726
      
      Review-Url: https://codereview.chromium.org/2655233002
      Cr-Commit-Position: refs/heads/master@{#42680}
      69747e26
  14. 23 Jan, 2017 1 commit
  15. 19 Dec, 2016 1 commit
  16. 12 Dec, 2016 1 commit
  17. 18 Nov, 2016 2 commits
  18. 03 Aug, 2016 2 commits
  19. 01 Aug, 2016 1 commit
  20. 11 Jul, 2016 1 commit
  21. 08 Jul, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Remove eager frame state from divisions. · b1cbb983
      mstarzinger authored
      This removes the frame state input representing the before-state from
      nodes having the {JSDivide} or the {JSModulus} operator. Lowering that
      inserts number conversions of the inputs has to be disabled when
      deoptimization is enabled, because the frame state layout is no longer
      known.
      
      R=jarin@chromium.org
      BUG=v8:5021
      
      Review-Url: https://codereview.chromium.org/2121153003
      Cr-Commit-Position: refs/heads/master@{#37608}
      b1cbb983
  22. 05 Jul, 2016 2 commits
  23. 03 Jun, 2016 3 commits
  24. 02 Jun, 2016 3 commits
    • mstarzinger's avatar
      [turbofan] Remove eager frame state from runtime calls. · a7ff6165
      mstarzinger authored
      This removes the frame state input representing the before-state from
      nodes having the {JSCallRuntime} operator. These frame states can by now
      be found via checkpoints in the graph. It also makes the predicate for
      runtime function ids (i.e. {Linkage::NeedsFrameStateInput}) binary.
      
      R=jarin@chromium.org
      BUG=v8:5021
      
      Review-Url: https://codereview.chromium.org/2018353004
      Cr-Commit-Position: refs/heads/master@{#36679}
      a7ff6165
    • jarin's avatar
      [turbofan] Initial version of number type feedback. · 216bcf9f
      jarin authored
      This introduces optimized number operations based on type feedback.
      
      Summary of changes:
      
      1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
         there is suitable feedback. The speculative nodes are connected to both the
         effect chain and the control chain and they retain the eager frame state.
      
      2. Simplified lowering now executes in three phases:
        a. Propagation phase computes truncations by traversing the graph from uses to
           definitions until checkpoint is reached. It also records type-check decisions
           for later typing phase, and computes representation.
        b. The typing phase computes more precise types base on the speculative types (and recomputes
           representation for affected nodes).
        c. The lowering phase performs lowering and inserts representation changes and/or checks.
      
      3. Effect-control linearization lowers the checks to machine graphs.
      
      Notes:
      
      - SimplifiedLowering will be refactored to have handling of each operation one place and
        with clearer input/output protocol for each sub-phase. I would prefer to do this once
        we have more operations implemented, and the pattern is clearer.
      
      - The check operations (Checked<A>To<B>) should have some flags that would affect
        the kind of truncations that they can handle. E.g., if we know that a node produces
        a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.
      
      - In future, we want the typer to reuse the logic from OperationTyper.
      
      BUG=v8:4583
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1921563002
      Cr-Commit-Position: refs/heads/master@{#36674}
      216bcf9f
    • mstarzinger's avatar
      [turbofan] Remove eager frame state from call nodes. · 864b07e9
      mstarzinger authored
      This removes the frame state input representing the before-state from
      nodes having the {JSCallFunction} or {JSCallConstruct} operator. These
      frame states can by now be found via checkpoints in the graph.
      
      R=bmeurer@chromium.org
      BUG=v8:5021
      
      Review-Url: https://codereview.chromium.org/2025573003
      Cr-Commit-Position: refs/heads/master@{#36669}
      864b07e9
  25. 01 Jun, 2016 1 commit
  26. 01 Apr, 2016 1 commit
  27. 11 Feb, 2016 1 commit
    • bmeurer's avatar
      [compiler] Sanitize entry points to LookupSlot access. · 4ff159bd
      bmeurer authored
      Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof,
      %LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and
      %StoreLookupSlot_Strict runtime entry points and use them
      appropriately in the various compilers. This way we can
      finally drop the machine operators from the JS graph level
      completely in TurboFan.
      
      Also drop the funky JSLoadDynamic operator from TurboFan,
      which was by now just a small wrapper around the runtime
      call to %LoadLookupSlot.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1683103002
      
      Cr-Commit-Position: refs/heads/master@{#33880}
      4ff159bd
  28. 09 Dec, 2015 1 commit
  29. 25 Nov, 2015 3 commits