1. 11 Jan, 2018 1 commit
  2. 30 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a dedicated StringLength operator. · 500d7b93
      Benedikt Meurer authored
      Strings are immutable in JavaScript land (contrast with the runtime,
      where we can truncate strings that haven't escaped to JavaScript yet),
      so the length of a String is immutable. Thus loading the length of a
      String is a pure operation and should be expressed as such (i.e. doesn't
      depend on control or effect). The StringLength operator does exactly
      this and is hooked up to the effect chain in the EffectControlLinearizer.
      
      This will eventually allow us to simplify the optimization of string
      concatention and other operations that are a bit cumbersome in TurboFan
      currently, and it will also allow us to optimize string operations
      across effectful operations, for example combining multiple invocations
      to String#slice with the same inputs.
      
      Bug: v8:5269, v8:6936, v8:7109, v8:7137
      Change-Id: Iffcccbb0c7fc4cfe1281c10e7af24b40eba4c987
      Reviewed-on: https://chromium-review.googlesource.com/799690Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49731}
      500d7b93
  3. 28 Nov, 2017 1 commit
  4. 21 Nov, 2017 3 commits
  5. 27 Oct, 2017 1 commit
  6. 19 Oct, 2017 1 commit
    • Mike Stanton's avatar
      [Turbofan] Model JSToBoolean as a simplified operator · 78fc6668
      Mike Stanton authored
      Because the toboolean operator may lower to a builtin call (which is
      effectful in turbofan parlance after effect control linearization),
      it really should be encoded as a simplified operator, which can
      be optimized with respect for the effect chain in linearization.
      
      No new functionality here, rather a furniture rearrangement in
      the TurboFan node structure.
      
      Bug: v8:6929
      Change-Id: I371fd22941397d5c28d13bded2738161d8da8275
      Reviewed-on: https://chromium-review.googlesource.com/725721Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48727}
      78fc6668
  7. 16 Oct, 2017 1 commit
    • Mike Stanton's avatar
      [TurboFan] Model TypeOf as a simplified operator · 9b2a8c22
      Mike Stanton authored
      Because the typeof operator may lower to a builtin call (which is
      effectful in turbofan parlance after effect control linearization),
      it really should be encoded as a simplified operator, which can
      be optimized with respect for the effect chain in linearization.
      
      No new functionality here, rather a furniture rearrangement in
      the TurboFan node structure.
      
      BUG=v8:6929
      
      Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e
      Reviewed-on: https://chromium-review.googlesource.com/718745Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48613}
      9b2a8c22
  8. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  9. 28 Aug, 2017 1 commit
  10. 11 Aug, 2017 1 commit
  11. 10 Aug, 2017 1 commit
  12. 19 Jul, 2017 1 commit
  13. 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
  14. 21 Jun, 2017 1 commit
  15. 19 Jun, 2017 1 commit
  16. 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
  17. 08 Jun, 2017 1 commit
    • Ross McIlroy's avatar
      [TurboFan] Add typing for the EmptyString and use this for JSToPrimitiveToString · 2c296b7e
      Ross McIlroy authored
      Add the ability for the typer to track whether a string could be the empty
      string. This is needed for typed lowering of JSStringConcat since we can't
      create cons string chain with the empty string in arbitrary positions.
      
      The ToPrimitiveToString bytecode handler is modified to collect feedback on
      whether it has ever seen the empty string, which is used by
      SpeculativeToPrimitiveToString to ensure that the output is non-empty (or
      depot) which will subsiquently be used to enable inline cons-string creation
      for the JSStringConcat operator in typed lowering in a subsiquent CL.
      
      BUG=v8:6243
      
      Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52
      Reviewed-on: https://chromium-review.googlesource.com/522122
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45786}
      2c296b7e
  18. 07 Jun, 2017 1 commit
  19. 18 May, 2017 2 commits
    • bmeurer's avatar
      [turbofan] Eliminate empty string addition. · cd1325a8
      bmeurer authored
      For additions like a+'' or ''+a where we have String feedback on the
      JSAdd, we can drop the concatenation and just check that a is a valid
      String already (via CheckString).
      
      BUG=v8:6259
      R=petermarshall@chromium.org
      
      Review-Url: https://codereview.chromium.org/2894563002
      Cr-Commit-Position: refs/heads/master@{#45395}
      cd1325a8
    • 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
  20. 03 May, 2017 1 commit
  21. 07 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce a SpeculativeToNumber operator. · e6ca0146
      bmeurer authored
      Add a dedicated operator for ToNumber(x) with feedback instead of
      translating to SpeculativeNumberMultiply(x,1), which allows us to
      treat the case where x is already a Number specially, ignoring the
      feedback on the operator. This recovers most of the regression in
      the crypto benchmark.
      
      BUG=chromium:709398,v8:6214,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2802113003
      Cr-Commit-Position: refs/heads/master@{#44484}
      e6ca0146
  22. 29 Mar, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Remove typeof optimization from typed lowering. · 0554e36b
      bmeurer authored
      Now that Ignition has the dedicated TestTypeOf operator, there's not
      really a point in doing the typeof with abstract/strict equal combining
      in TurboFan anymore. In fact it's counter-productive to do so, as it
      might try to cover typeof comparisons in cases where it's better to just
      compute the typeof once, i.e.:
      
        let x = typeof a, y = typeof b;
        if (x === y) {
          if (x === 'string') {
            ...
          }
        }
      
      Here we would combine the second comparison into an ObjectIsString, and
      still compute the typeof a.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2780953003
      Cr-Commit-Position: refs/heads/master@{#44220}
      0554e36b
  23. 07 Mar, 2017 1 commit
  24. 03 Mar, 2017 1 commit
  25. 28 Feb, 2017 1 commit
  26. 22 Feb, 2017 2 commits
  27. 20 Feb, 2017 2 commits
  28. 16 Feb, 2017 1 commit
  29. 15 Feb, 2017 1 commit
  30. 09 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Utilize the fact that empty string is canonicalized. · cd9724d4
      bmeurer authored
      Since the empty string is canonical HeapObject now, we can use
      this fact to optimize
      
        - strict equality comparisons with the empty string to a
          simple ReferenceEqual operation, and
        - optimize ToBoolean to avoid instance type checks completely.
      
      Drive-by-fix: Allow InternalizedString for Type::HeapConstant
      in the type system. This is safe, since InternalizedStrings
      can be compared to other heap constants by reference (except
      for non-InternalizedStrings, which are excluded from the
      HeapConstant type).
      
      BUG=v8:5267
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2681273002
      Cr-Commit-Position: refs/heads/master@{#43050}
      cd9724d4
  31. 01 Feb, 2017 2 commits
  32. 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
  33. 18 Jan, 2017 1 commit
  34. 09 Jan, 2017 1 commit