1. 05 Aug, 2016 1 commit
    • danno's avatar
      [stubs] Convert GrowElementsStub to TurboFan · eb841269
      danno authored
      One caveat: the Crankshaft stub used to preserve callee-clobbered double
      registers, which is contrary to any real platform ABI that we support. Since the
      only current use of this stub is in Crankshaft, the instruction there now must
      be marked as double-clobbering. This might result in a small performance
      regression. However, when this stub is eventually used in TF-generated code, it
      will be called from deferred code that can save doubles only on the rarely-taken
      path... something that Crankshaft can't do.
      
      BUG=chromium:608675
      
      Review-Url: https://codereview.chromium.org/2206333003
      Cr-Commit-Position: refs/heads/master@{#38371}
      eb841269
  2. 30 Jun, 2016 1 commit
  3. 27 Jun, 2016 1 commit
  4. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  5. 17 Jun, 2016 2 commits
    • bmeurer's avatar
      [builtins] Introduce proper Float64Cos and Float64Sin. · c781e831
      bmeurer authored
      Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
      introduce Float64Cos and Float64Sin TurboFan operator based on that,
      similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
      as TurboFan builtins and use those operators to also inline Math.cos()
      and Math.sin() into optimized TurboFan functions.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      R=mvstanton@chromium.org
      BUG=v8:5086,v8:5118
      
      Review-Url: https://codereview.chromium.org/2073123002
      Cr-Commit-Position: refs/heads/master@{#37072}
      c781e831
    • bmeurer's avatar
      [builtins] Introduce proper Float64Exp operator. · d5f2ac5e
      bmeurer authored
      Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.exp() as TurboFan builtin and use that operator to also
      inline Math.exp() into optimized TurboFan functions.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
      R=mvstanton@chromium.org
      
      Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
      Review-Url: https://codereview.chromium.org/2077533002
      Cr-Original-Commit-Position: refs/heads/master@{#37037}
      Cr-Commit-Position: refs/heads/master@{#37047}
      d5f2ac5e
  6. 16 Jun, 2016 2 commits
  7. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored
      This adds back the instanceof operator support in the backends and
      introduces a @@hasInstance protector cell on the isolate that guards the
      fast path for the InstanceOfStub. This way we recover the ~10%
      regression on Octane EarleyBoyer in Crankshaft and greatly improve
      TurboFan and Ignition performance of instanceof.
      
      R=ishell@chromium.org
      TBR=hpayer@chromium.org,rossberg@chromium.org
      BUG=chromium:597249, v8:4447
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1980483003
      Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  8. 10 May, 2016 1 commit
  9. 30 Mar, 2016 1 commit
  10. 21 Mar, 2016 1 commit
  11. 16 Mar, 2016 2 commits
  12. 08 Mar, 2016 1 commit
    • verwaest's avatar
      Don't do any special normalization if a boilerplate contains function literals. · fd405704
      verwaest authored
      This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
      
      function.prototype = {
        method: function() { ... }
      }
      
      Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
      
      This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
      
      BUG=chromium:593008
      LOG=n
      
      Review URL: https://codereview.chromium.org/1772423002
      
      Cr-Commit-Position: refs/heads/master@{#34602}
      fd405704
  13. 07 Mar, 2016 1 commit
    • ishell's avatar
      [crankshaft] Support ES6 tail call elimination. · 22938040
      ishell authored
      HInvokeFunction and HApplyArguments instructions now support tail calling.
      
      Inlining of calls at tail position is not supported yet and therefore still disabled.
      
      The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft.
      
      TBR=bmeurer@chromium.org
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1760253003
      
      Cr-Commit-Position: refs/heads/master@{#34542}
      22938040
  14. 26 Feb, 2016 1 commit
  15. 24 Feb, 2016 1 commit
  16. 17 Feb, 2016 2 commits
  17. 16 Feb, 2016 1 commit
  18. 09 Feb, 2016 1 commit
    • bmeurer's avatar
      [intrinsics] Kill the %_IsMinusZero intrinsic. · 00f7d1f5
      bmeurer authored
      By now only the default %TypedArray%.prototype.sort compare function
      and the JS implementation of SameValueZero were still using the odd
      %_IsMinusZero intrinsic, whose semantics both included a number check
      (actually HeapNumber test) plus testing if the heap number stores the
      special -0 value. In both cases we already know that we deal with
      number so we can reduce it to a simple number test for -0, which can
      be expressed via dividing 1 by that value and checking the sign of
      the result. In case of the compare function, we can be even smarter
      and work with the reciprocal values in case x and y are equal to 0
      (although long term we should probably rewrite the fast case for
      the typed array sorting function in C++ anyway, which will be way,
      way faster than our handwritten callback-style, type-feedback
      polluted JS implementation).
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1680783002
      
      Cr-Commit-Position: refs/heads/master@{#33833}
      00f7d1f5
  19. 21 Jan, 2016 1 commit
  20. 12 Jan, 2016 3 commits
  21. 07 Dec, 2015 1 commit
  22. 03 Dec, 2015 1 commit
  23. 01 Dec, 2015 1 commit
  24. 25 Nov, 2015 1 commit
    • bmeurer's avatar
      [runtime] First step to sanitize regexp literal creation. · 09b44428
      bmeurer authored
      This is the initial step towards refactoring the regexp literation
      creation code to make it less obscure and more similar to the mechanism
      we use to create array and object literals.  There's now a new runtime
      entry %CreateRegExpLiteral with the same interface as the entries for
      array and object literals, except that we still pass the flags as
      string.
      
      Instead of embedding the hand written native to clone JSRegExp instances
      we now have a FastCloneRegExpStub, which behaves similar to the other
      FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already
      had.
      
      R=mlippautz@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1475823003
      
      Cr-Commit-Position: refs/heads/master@{#32255}
      09b44428
  25. 23 Nov, 2015 1 commit
    • bmeurer's avatar
      [builtins] Sanitize the machinery around Construct calls. · 374b6ea2
      bmeurer authored
      There's no point in collecting feedback for super constructor calls,
      because in all (interesting) cases we can gather (better) feedback from
      other sources (i.e. via inlining or via using a LOAD_IC to get to the
      [[Prototype]] of the target).  So CallConstructStub is now only used
      for new Foo(...args) sites where we want to collect feedback in the
      baseline compiler.  The optimizing compilers, Reflect.construct and
      super constructor calls use the Construct builtin directly, which allows
      us to remove some weird code from the CallConstructStub (and opens the
      possibility for more code sharing with the CallICStub, maybe even going
      for a ConstructICStub).
      
      Also remove the 100% redundant HCallNew instruction, which is just a
      wrapper for the Construct builtin anyway (indirectly via the
      CallConstructStub).
      
      Drive-by-fix: Drop unused has_function_cache bit on Code objects.
      
      R=mstarzinger@chromium.org, yangguo@chromium.org
      BUG=v8:4413, v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1469793002
      
      Cr-Commit-Position: refs/heads/master@{#32172}
      374b6ea2
  26. 22 Oct, 2015 1 commit
  27. 20 Oct, 2015 1 commit
  28. 30 Sep, 2015 1 commit
  29. 10 Sep, 2015 1 commit
    • bmeurer's avatar
      [runtime] Sanitize %NewClosure runtime entries. · 6b3c070d
      bmeurer authored
      There are now two runtime entries %NewClosure and %NewClosure_Tenured,
      with the same signature (one parameter, the SharedFunctionInfo, and the
      context of the caller).
      
      Also remove the HFunctionLiteral special case instruction from Crankshaft,
      as HCallWithDescriptor with FastNewClosureStub or HCallRuntime with
      either %NewClosure or %NewClosure_Tenured can easily do that for you.
      
      Also remove the redundant context parameter from the JSCreateClosure
      operator, because every JS operator already takes a context input.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg
      
      Review URL: https://codereview.chromium.org/1329293003
      
      Cr-Commit-Position: refs/heads/master@{#30671}
      6b3c070d
  30. 01 Sep, 2015 1 commit
  31. 26 Aug, 2015 1 commit
  32. 25 Aug, 2015 1 commit
    • bmeurer's avatar
      Correctify instanceof and make it optimizable. · 5d875a57
      bmeurer authored
      The previous hack with HInstanceOfKnownGlobal was not only slower,
      but also very brittle and required a lot of weird hacks to support it. And
      what's even more important it wasn't even correct (because a map check
      on the lhs is never enough for instanceof).
      
      The new implementation provides a sane runtime implementation
      for InstanceOf plus a fast case in the InstanceOfStub, combined with
      a proper specialization in the case of a known global in CrankShaft,
      which does only the prototype chain walk (coupled with a code
      dependency on the known global).
      
      As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
      implementation.
      
      BUG=v8:4376
      LOG=y
      
      Review URL: https://codereview.chromium.org/1304633002
      
      Cr-Commit-Position: refs/heads/master@{#30342}
      5d875a57
  33. 28 Jul, 2015 1 commit
  34. 20 Jul, 2015 1 commit