1. 07 Sep, 2017 1 commit
  2. 28 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [runtime] Cleanup native methods creation in js/v8natives.js. · 36b33251
      Igor Sheludko authored
      This CL replaces usages of utils.InstallFunctions and utils.InstallGetter()
      with the DEFINE_METHOD* macros that ensure that the native function is
      created in proper form from the beginning. Thus the function will not
      require further reconfiguring like adding a computed name or removing of
      'prototype' property.
      
      This CL is one of a series of cleanup CL which are the preliminary steps for
      improving function closures creation.
      
      Bug: v8:6459
      Change-Id: Iebee37861fbe026b421aeac19dc838302a9e106d
      Reviewed-on: https://chromium-review.googlesource.com/548136
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46284}
      36b33251
  3. 27 Jun, 2017 3 commits
  4. 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
  5. 14 Apr, 2017 1 commit
  6. 03 Mar, 2017 1 commit
  7. 02 Mar, 2017 3 commits
  8. 27 Feb, 2017 1 commit
  9. 18 Oct, 2016 1 commit
  10. 14 Oct, 2016 4 commits
  11. 07 Oct, 2016 1 commit
  12. 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
  13. 09 Aug, 2016 1 commit
  14. 12 Jul, 2016 1 commit
  15. 05 Jul, 2016 3 commits
  16. 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
  17. 30 Jun, 2016 1 commit
  18. 28 Jun, 2016 1 commit
    • 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
  19. 30 May, 2016 1 commit
  20. 24 May, 2016 1 commit
  21. 29 Apr, 2016 2 commits
  22. 28 Apr, 2016 1 commit
  23. 25 Apr, 2016 3 commits
  24. 22 Apr, 2016 1 commit
  25. 25 Mar, 2016 1 commit
  26. 01 Mar, 2016 1 commit
  27. 29 Feb, 2016 1 commit
  28. 17 Feb, 2016 1 commit