1. 03 Jun, 2016 1 commit
  2. 18 May, 2016 1 commit
  3. 10 May, 2016 1 commit
  4. 06 May, 2016 1 commit
  5. 07 Apr, 2016 1 commit
  6. 01 Apr, 2016 1 commit
  7. 30 Mar, 2016 1 commit
  8. 23 Mar, 2016 1 commit
  9. 22 Mar, 2016 2 commits
  10. 21 Mar, 2016 1 commit
  11. 16 Mar, 2016 1 commit
  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. 29 Feb, 2016 2 commits
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
      our naming convention, and add a new TurboFan-powered ToBooleanStub,
      which just does the ToBoolean conversion without any runtime call or
      code patching, so we can use it for Ignition (and TurboFan).
      
      Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
      already have for to_string and to_number, so we don't need to actually
      dispatch on the concrete Oddball at all.
      
      R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1744163002
      
      Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
    • zhengxing.li's avatar
      X87: [crankshaft] [ia32] Remove dynamic frame alignment optimization. · e99ad691
      zhengxing.li authored
        port fcb83f20(r34273)
      
        original commit message:
        This optimization does not give us much (see perf try bot results associated with this CL) but complicates things a lot. The main motivation is to avoid additional complexity in tail call optim
      
        There are some pieces left in the deoptimizer, but I'll address this in a separate CL.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1750433002
      
      Cr-Commit-Position: refs/heads/master@{#34353}
      e99ad691
  14. 26 Feb, 2016 1 commit
  15. 24 Feb, 2016 1 commit
  16. 19 Feb, 2016 1 commit
  17. 17 Feb, 2016 2 commits
  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 3 commits
  20. 12 Jan, 2016 3 commits
  21. 07 Dec, 2015 1 commit
  22. 04 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. 24 Nov, 2015 1 commit
    • zhengxing.li's avatar
      X87: [builtins] Sanitize the machinery around Construct calls. · 4620a235
      zhengxing.li authored
        port 374b6ea2 (r32172)
      
        original commit message:
        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.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1471193002
      
      Cr-Commit-Position: refs/heads/master@{#32197}
      4620a235
  26. 23 Oct, 2015 1 commit
    • zhengxing.li's avatar
      X87: Re-reland: Remove register index/code indirection. · 2e5845f1
      zhengxing.li authored
          port 5cf1c0bc (r31087).
      
          original commit message:
          Previous to this patch, both the lithium and TurboFan register
          allocators tracked allocated registers by "indices", rather than
          the register codes used elsewhere in the runtime. This patch
          ensures that codes are used everywhere, and in the process cleans
          up a bunch of redundant code and adds more structure to how the
          set of allocatable registers is defined.
      
          Some highlights of changes:
      
          * TurboFan's RegisterConfiguration class moved to V8's top level
            so that it can be shared with Crankshaft.
          * Various "ToAllocationIndex" and related methods removed.
          * Code that can be easily shared between Register classes on
            different platforms is now shared.
          * The list of allocatable registers on each platform is declared
            as a list rather than implicitly via the register index <->
            code mapping.
      
          additional comment:
          This patch must be work with CL https://codereview.chromium.org/1405673003/
          and CL https://codereview.chromium.org/1413343002/
          which provide the needed register allocation common code change in
          v8 for this CL
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1410393004
      
      Cr-Commit-Position: refs/heads/master@{#31494}
      2e5845f1
  27. 22 Oct, 2015 1 commit
  28. 20 Oct, 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. 07 Sep, 2015 1 commit
  31. 03 Sep, 2015 1 commit
  32. 26 Aug, 2015 2 commits
    • bmeurer's avatar
      [runtime] Remove the redundant %_IsObject intrinsic. · b4c73994
      bmeurer authored
      %_IsObject(foo) is equivalent to typeof foo === 'object' and has
      exactly the same optimizations, so there's zero need for %_IsObject
      in our code base.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1313903003
      
      Cr-Commit-Position: refs/heads/master@{#30380}
      b4c73994
    • chunyang.dai's avatar
      X87: Correctify instanceof and make it optimizable. · 3aeed04d
      chunyang.dai authored
      port 5d875a57 (r30342).
      
      original commit message:
      
          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.
      
      R=weiliang.lin@intel.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1318663003
      
      Cr-Commit-Position: refs/heads/master@{#30376}
      3aeed04d