1. 17 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Inline Function#bind in more cases. · 594803c9
      Benedikt Meurer authored
      So far the inlining of Function#bind into TurboFan optimized code was
      limited to cases where TurboFan could infer the constant JSFunction that
      was bound. However we can easily extend that to cover JSBoundFunction as
      well, and obviously also take the LOAD_IC feedback if we don't have a
      known JSFunction or JSBoundFunction.
      
      This adds a new operator JSCreateBoundFunction that contains the logic
      for the creation of the bound function object and the arguments.
      
      On the micro-benchmarks we go from
      
        functionBindParameter0: 1239 ms.
        functionBindConstant0: 478 ms.
        functionBindBoundConstant0: 1256 ms.
        functionBindParameter1: 1278 ms.
        functionBindConstant1: 475 ms.
        functionBindBoundConstant1: 1253 ms.
        functionBindParameter2: 1431 ms.
        functionBindConstant2: 616 ms.
        functionBindBoundConstant2: 1437 ms.
      
      to
      
        functionBindParameter0: 462 ms.
        functionBindConstant0: 485 ms.
        functionBindBoundConstant0: 474 ms.
        functionBindParameter1: 478 ms.
        functionBindConstant1: 474 ms.
        functionBindBoundConstant1: 474 ms.
        functionBindParameter2: 617 ms.
        functionBindConstant2: 614 ms.
        functionBindBoundConstant2: 616 ms.
      
      which is a ~2.5x improvement. On the jshint benchmark in the
      web-tooling-benchmark we observe a 2-3% improvement, which corresponds
      to the time we had seen it running in the generic version.
      
      Bug: v8:6936, v8:6946
      Change-Id: I940d13220ff35ae602dbaa33349ba4bbe0c9a9d3
      Reviewed-on: https://chromium-review.googlesource.com/723080Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48639}
      594803c9
  2. 04 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize Object.is baseline and interesting cases. · d4da17c6
      Benedikt Meurer authored
      The Object.is builtin provides an entry point to the abstract operation
      SameValue, which properly distinguishes -0 and 0, and also identifies
      NaNs. Most of the time you don't need these, but rather just regular
      strict equality, but when you do, Object.is(o, -0) is the most readable
      way to check for minus zero.
      
      This is for example used in Node.js by formatNumber to properly print -0
      for negative zero. However since the builtin thus far implemented as C++
      builtin and TurboFan didn't know anything about it, Node.js considering
      to go with a more performant, less readable version (which also makes
      assumptions about the input value) in
      
        https://github.com/nodejs/node/pull/15726
      
      until the performance of Object.is will be on par (so hopefully we can
      go back to Object.is in Node 9).
      
      This CL ports the baseline implementation of Object.is to CSA, which
      is pretty straight-forward since SameValue is already available in
      CodeStubAssembler, and inlines a few interesting cases into TurboFan,
      i.e. comparing same SSA node, and checking for -0 and NaN explicitly.
      
      On the micro-benchmarks we go from
      
        testNumberIsMinusZero: 1000 ms.
        testObjectIsMinusZero: 929 ms.
        testObjectIsNaN: 954 ms.
        testObjectIsSame: 793 ms.
        testStrictEqualSame: 104 ms.
      
      to
      
        testNumberIsMinusZero: 89 ms.
        testObjectIsMinusZero: 88 ms.
        testObjectIsNaN: 88 ms.
        testObjectIsSame: 86 ms.
        testStrictEqualSame: 105 ms.
      
      which is a nice 10x to 11x improvement and brings Object.is on par with
      strict equality for most cases.
      
      Drive-by-fix: Also refactor and optimize the SameValue check in the
      CodeStubAssembler to avoid code bloat (by not inlining StrictEqual
      into every user of SameValue, and also avoiding useless checks).
      
      Bug: v8:6882
      Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344
      Reviewed-on: https://chromium-review.googlesource.com/700254Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48275}
      d4da17c6
  3. 02 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize TypedArray.prototype[Symbol.toStringTag]. · b8b76eba
      Benedikt Meurer authored
      The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
      as far as I can tell only definitely side-effect free) way to check whether an
      arbitrary object is a TypedArray - either generally TypedArray or a specific
      one like Uint8Array. Using the getter is thus emerging as the general pattern
      to detect TypedArrays, even Node.js now adapted it starting with
      
        https://github.com/nodejs/node/pull/15663
      
      for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
      now.
      
      The getter returns either the string with the TypedArray subclass name
      (i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
      This can be implemented with a simple elements kind dispatch, instead of
      checking the instance type and then loading the class name from the
      constructor, which requires a loop walking up the transition tree. This
      CL ports the builtin to CSA and TurboFan, and changes the logic to a
      simple elements kind check. On the micro-benchmark mentioned in the
      referenced bug, the time goes from
      
        testIsArrayBufferView: 565 ms.
        testIsTypedArray: 2403 ms.
        testIsUint8Array: 3847 ms.
      
      to
      
        testIsArrayBufferView: 566 ms.
        testIsTypedArray: 965 ms.
        testIsUint8Array: 965 ms.
      
      which presents an up to 4x improvement.
      
      Bug: v8:6874
      Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
      Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48254}
      b8b76eba
  4. 30 Sep, 2017 1 commit
  5. 05 Sep, 2017 1 commit
  6. 10 Aug, 2017 1 commit
  7. 14 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Inline Map and Set iterators into optimized code. · 1287688c
      Benedikt Meurer authored
      This CL inlines the following builtins into TurboFan
      
        - %MapIteratorPrototype%.next
        - %SetIteratorPrototype%.next
      
      following the design that we are using for Array iteration already
      (different instance types for the different kinds of iterators). Details
      can be found in the relevant design document at:
      
        https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8
      
      The key to great performance here is to ensure that the inlined code
      allows escape analysis and scalar replacement of aggregates to remove
      the allocations for the iterator itself as well as the iterator results
      and potential key/value arrays in the simple case of a for-of loop (and
      by extension also in other constructs that reduce to for-of loops
      internally), i.e.:
      
        const s = new Set;
        // ... do something with s
        for (const x of s) {
          // ...
        }
      
      Here the for-of loop shouldn't perform any allocations of helper
      objects.
      
      Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more
      general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also
      migrate the {Map,Set}.prototype.size getter inlining to the
      JSBuiltinReducer, so that everything is in a single place.
      
      R=jgruber@chromium.org
      
      Bug: v8:6344, v8:6571, chromium:740122
      Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d
      Reviewed-on: https://chromium-review.googlesource.com/570159Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46655}
      1287688c
  8. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored
      Each reducer now has a virtual reducer_name function, returning its name
      (the name of the class containing this reducer). This gets displayed when
      using the --trace_turbo_reduction flag. Also when using this flags more
      messages are displayed.
      
      Actually when a node is replaced in-place (which is called an update
      of the node), other reducers can still update it right after the
      in-place replacement. When a node is really replaced (not in-place),
      then we stop trying to apply reducers to it before we propagate the
      reduction through the relevant nodes.
      
      Before a message got printed only for the last reduction it went
      through. So in case a node was reduced in-place several times
      in a row, only the last update was printed, or none at all if after
      being reduced in-place it got reduced by being replaced by another
      node: only the non-in-place replacement was showed. 
      
      Now each time an in-place reduction is applied to a node, a message
      gets printed.
      
      Bug: 
      Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
      Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34
  9. 10 Jul, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Initial optimization of Map.prototype.(get|has) in Turbofan. · aba708a1
      Jaroslav Sevcik authored
      This introduces a new builtin (MapLookupHashIndex) and uses it
      in Turbofan to compute Map.p.get and Map.p.has.
      
      I have also refactored the existing CSA builtins for Map.p.get and 
      Map.p.has to use the new builtin under the hood.
      
      The code for the lookup has been also improved.
      - Specialized lookups for smis, strings, heap numbers and everything else.
        - the advantage is that we can use fast equalities for the lookup.
        - strings can likely be optimized further if we care about the 
          internalized string fast case.
      - Instead of a call to runtime to get the hash code, we now call C directly.
      
      In the Turbofan implementation itself, there are no special optimizations yet.
      The next step is to teach load elimination to reuse the indexes from
      previous calls of MapLookupHashIndex. 
      
      BUG=v8:6410
      
      Change-Id: I0b1a70493eb031d444e51002f6b2cc1f30ea2b68
      Reviewed-on: https://chromium-review.googlesource.com/560169Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46510}
      aba708a1
  10. 26 Jun, 2017 1 commit
  11. 02 Jun, 2017 1 commit
  12. 10 May, 2017 1 commit
  13. 20 Mar, 2017 1 commit
  14. 27 Feb, 2017 1 commit
  15. 26 Jan, 2017 1 commit
  16. 13 Jan, 2017 3 commits
  17. 03 Jan, 2017 1 commit
  18. 29 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Also optimize instanceof with bound functions. · 719d6c1d
      bmeurer authored
      For bound functions on the right-hand side of instanceof we can
      constant-fold to the actual [[BoundTargetFunction]], actually
      instance OrdinaryHasInstance. Move the Function.prototype[@@hasInstance]
      reduction up to the JSCallReducer to allow this optimization to become
      effective (and also enable other optimizations).
      
      BUG=v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2537763002
      Cr-Commit-Position: refs/heads/master@{#41352}
      719d6c1d
  19. 18 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Properly optimize instanceof (even in the presence of @@hasInstance). · 241c024c
      bmeurer authored
      This is the TurboFan counterpart of http://crrev.com/2504263004, but it
      is a bit more involved, since in TurboFan we always inline the appropriate
      call to the @@hasInstance handler, and by that we can optimize a lot more
      patterns of instanceof than Crankshaft, and even yield fast instanceof
      for custom @@hasInstance handlers (which we can now properly inline as
      well).
      
      Also we now properly optimize Function.prototype[@@hasInstance], even if
      the right hand side of an instanceof doesn't have the Function.prototype
      as its direct prototype.
      
      For the baseline case, we still rely on the global protector cell, but
      we can address that in a follow-up as well, and make it more robust in
      general.
      
      TEST=mjsunit/compiler/instanceof
      BUG=v8:5640
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2511223003
      Cr-Commit-Position: refs/heads/master@{#41092}
      241c024c
  20. 14 Nov, 2016 1 commit
  21. 03 Nov, 2016 1 commit
  22. 18 Oct, 2016 1 commit
  23. 17 Oct, 2016 1 commit
  24. 05 Oct, 2016 3 commits
  25. 07 Sep, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Number predicates and make them optimizable. · 7ac19fe5
      bmeurer authored
      Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
      Number.isSafeInteger and Number.isNaN predicates to TurboFan
      builtins and make them optimizable (for certain input types) in
      JavaScript callees being optimized by TurboFan. That means both
      the baseline and the optimized version is now always at maximum,
      consistent performance. Especially TurboFan suffered from poor
      baseline (and optimized) performance because it cannot play the
      same weird tricks that Crankshaft plays for %_IsSmi.
      
      This also adds a bunch of new tests to properly cover the use
      of the Harmony predicates in optimized code.
      
      R=franzih@chromium.org
      BUG=v8:5049,v8:5267
      
      Review-Url: https://codereview.chromium.org/2313073002
      Cr-Commit-Position: refs/heads/master@{#39242}
      7ac19fe5
  26. 29 Aug, 2016 2 commits
  27. 12 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add inlined Array.prototype.push support. · 50f223e4
      bmeurer authored
      This adds a very first version of inlined Array.prototype.push into
      TurboFan optimized code. The current inlined version has a potential
      deopt loop, but it's unlikely that we hit it currently (Crankshaft
      suffers from an even worse problem). Once we have a way to learn from
      deopts we can fix this deopt loops.
      
      It's also probably overly defensive in when it's safe to inline
      the call to Array.prototype.push, but we can always extend that
      later once we have sufficient trust in the implementation and see
      an actual need to extend it.
      
      BUG=v8:2229,v8:3952,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2245533003
      Cr-Commit-Position: refs/heads/master@{#38603}
      50f223e4
  28. 11 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add inlined Array.prototype.pop support. · b8f47504
      bmeurer authored
      This adds a very first version of inlined Array.prototype.pop into
      TurboFan optimized code. We currently limit the inlining to fast
      object or smi elements, until the unclear situation around hole NaNs
      is resolved and we have a clear semantics inside the compiler.
      
      It's also probably overly defensive in when it's safe to inline
      the call to Array.prototype.pop, but we can always extend that
      later once we have sufficient trust in the implementation and see
      an actual need to extend it.
      
      BUG=v8:2229,v8:3952,v8:5267
      R=epertoso@chromium.org
      
      Review-Url: https://codereview.chromium.org/2239703002
      Cr-Commit-Position: refs/heads/master@{#38578}
      b8f47504
  29. 01 Aug, 2016 1 commit
  30. 27 Jul, 2016 1 commit
  31. 05 Jul, 2016 1 commit
  32. 01 Jul, 2016 1 commit
    • bmeurer's avatar
      [builtins] Unify most of the remaining Math builtins. · 0a0fe8fb
      bmeurer authored
      Import fdlibm versions of acos, acosh, asin and asinh, which are more
      precise and produce the same result across platforms (we were using
      libm versions for asin and acos so far, where both speed and precision
      depended on the operating system so far). Introduce appropriate TurboFan
      operators for these functions and use them both for inlining and for the
      generic builtin.
      
      Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
      to ensure that their behavior is always exactly the same as the inlined
      TurboFan version (i.e. C++ truncation semantics for double to float
      don't necessarily meet the JavaScript semantics).
      
      For completeness, also migrate Math.sign, which can even get some nice
      love in TurboFan.
      
      Drive-by-fix: Some alpha-sorting on the Math related functions, and
      cleanup the list of Math intrinsics that we have to export via the
      native context currently.
      
      BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
      TBR=rossberg@chromium.org
      R=franzih@chromium.org
      
      Review-Url: https://codereview.chromium.org/2116753002
      Cr-Commit-Position: refs/heads/master@{#37476}
      0a0fe8fb
  33. 30 Jun, 2016 1 commit
  34. 28 Jun, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored
      Introduce a new machine operator Float64Pow that for now is backed by
      the existing MathPowStub to start the unification of Math.pow, and at
      the same time address the main performance issue that TurboFan still has
      with the imaging-darkroom benchmark in Kraken.
      
      Also migrate the Math.pow builtin itself to a TurboFan builtin and
      remove a few hundred lines of hand-written platform code for special
      handling of the fullcodegen Math.pow version.
      
      BUG=v8:3599,v8:5086,v8:5157
      
      Review-Url: https://codereview.chromium.org/2103733003
      Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
    • bmeurer's avatar
      [turbofan] Introduce simplified operator NumberAbs. · f50a601f
      bmeurer authored
      Add NumberAbs operator to implement an inline version of Math.abs, that
      can be optimized and eliminated. We don't use any speculation here, but
      for now stick to the information we can infer (this way we avoid the
      inherent deopt loops that Crankshaft has around Math.abs).
      
      CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
      R=jarin@chromium.org
      BUG=v8:5086
      
      Review-Url: https://codereview.chromium.org/2096403002
      Cr-Commit-Position: refs/heads/master@{#37306}
      f50a601f