1. 30 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Run everything after representation selection concurrently. · d1b3d426
      bmeurer authored
      Further refactor the pipeline to even run the first scheduler (part of
      the effect control linearization) concurrently. This temporarily
      disables most of the write barrier elimination, but we will get back to
      that later.
      
      Drive-by-fix: Remove the dead code from ChangeLowering, and stack
      allocate the Typer in the pipeline. Also migrate the AllocateStub to a
      native code builtin, so that we have the code object + a handle to it
      available all the time.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
      R=mstarzinger@chromium.org
      BUG=v8:4969
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1926023002
      Cr-Commit-Position: refs/heads/master@{#35918}
      d1b3d426
  2. 26 Apr, 2016 1 commit
  3. 19 Apr, 2016 1 commit
  4. 15 Apr, 2016 1 commit
  5. 06 Apr, 2016 1 commit
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored
      Introduce a ResumeGeneratorTrampoline, which does the actual stack state
      reconstruction (currently always restores a fullcodegen frame), and
      introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
      %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
      this native builtin.
      
      Also unify the flooding in case of step-in to always work based on
      JSFunction and remove the special casing for JSGeneratorObject.
      
      R=mstarzinger@chromium.org, neis@chromium.org
      TBR=rossberg@chromium.org
      BUG=chromium:513471
      LOG=n
      
      Review URL: https://codereview.chromium.org/1865833002
      
      Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  6. 21 Mar, 2016 1 commit
    • bmeurer's avatar
      [stubs] Split ToNumberStub into reusable subparts. · b7aa4c3a
      bmeurer authored
      Split ToNumberStub into the entry ToNumberStub, and two new stubs,
      StringToNumberStub and NonNumberToNumberStub, which can be used when we
      already know something about the input (i.e. in various branches of the
      code stubs, or in TurboFan graphs).
      
      Also introduce an appropriate StringToNumber simplified operator for
      TurboFan, that is pure and is lowered to an invocation of the newly
      added StringToNumberStub.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1818923002
      
      Cr-Commit-Position: refs/heads/master@{#34922}
      b7aa4c3a
  7. 15 Mar, 2016 1 commit
  8. 14 Mar, 2016 1 commit
  9. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored
      Before this CL, various code stubs used different techniques
      for marking their frames to enable stack-crawling and other
      access to data in the frame. All of them were based on a abuse
      of the "standard" frame representation, e.g. storing the a
      context pointer immediately below the frame's fp, and a
      function pointer after that. Although functional, this approach
      tends to make stubs and builtins do an awkward, unnecessary
      dance to appear like standard frames, even if they have
      nothing to do with JavaScript execution.
      
      This CL attempts to improve this by:
      
      * Ensuring that there are only two fundamentally different
        types of frames, a "standard" frame and a "typed" frame.
        Standard frames, as before, contain both a context and
        function pointer. Typed frames contain only a minimum
        of a smi marker in the position immediately below the fp
        where the context is in standard frames.
      * Only interpreted, full codegen, and optimized Crankshaft and
        TurboFan JavaScript frames use the "standard" format. All
        other frames use the type frame format with an explicit
        marker.
      * Typed frames can contain one or more values below the
        type marker. There is new magic macro machinery in
        frames.h that simplifies defining the offsets of these fields
        in typed frames.
      * A new flag in the CallDescriptor enables specifying whether
        a frame is a standard frame or a typed frame. Secondary
        register location spilling is now only enabled for standard
        frames.
      * A zillion places in the code have been updated to deal with
        the fact that most code stubs and internal frames use the
        typed frame format. This includes changes in the
        deoptimizer, debugger, and liveedit.
      * StandardFrameConstants::kMarkerOffset is deprecated,
        (CommonFrameConstants::kContextOrFrameTypeOffset
        and StandardFrameConstants::kFrameOffset are now used
        in its stead).
      
      LOG=N
      
      Review URL: https://codereview.chromium.org/1696043002
      
      Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  10. 07 Mar, 2016 2 commits
  11. 19 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a dedicated FastNewObjectStub. · ba2077aa
      bmeurer authored
      Move the already existing fast case for %NewObject into a dedicated
      FastNewObjectStub that we can utilize in places where we would otherwise
      fallback to %NewObject immediately, which is rather expensive.
      
      Also use FastNewObjectStub as the generic implementation of JSCreate,
      which should make constructor inlining based on SharedFunctionInfo (w/o
      specializing to a concrete closure) viable soon.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1708313002
      
      Cr-Commit-Position: refs/heads/master@{#34136}
      ba2077aa
  12. 10 Feb, 2016 1 commit
    • mlippautz's avatar
      [heap] Move to page lookups for SemiSpace, NewSpace, and Heap containment methods · cfbd2561
      mlippautz authored
      Preparing the young generation for (real) non-contiguous backing memory, this
      change removes object masks that are used to compute containment in semi and new
      space. The masks are replaced by lookups for object tags and page headers, where
      possible.
      
      Details:
      - Use the fast checks (page header lookups) for containment in regular code.
      - Use the slow version that masks out the page start adress and iterates all
        pages of a space for debugging/verification.
      - The slow version works for off-heap/unmapped memory.
      - Encapsulate all checks for the old->new barrier in Heap::RecordWrite().
      
      BUG=chromium:581412
      LOG=N
      
      Review URL: https://codereview.chromium.org/1632913003
      
      Cr-Commit-Position: refs/heads/master@{#33857}
      cfbd2561
  13. 04 Feb, 2016 1 commit
  14. 28 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Make Math.max and Math.min fast by default. · cb9b8010
      bmeurer authored
      The previous versions of Math.max and Math.min made it difficult to
      optimize those (that's why we already have custom code in Crankshaft),
      and due to lack of ideas what to do about the variable number of
      arguments, we will probably need to stick in special code in TurboFan
      as well; so inlining those builtins is off the table, hence there's no
      real advantage in having them around as "not quite JS" with extra work
      necessary in the optimizing compilers to still make those builtins
      somewhat fast in cases where we cannot inline them (also there's a
      tricky deopt loop in Crankshaft related to Math.min and Math.max, but
      that will be dealt with later).
      
      So to sum up: Instead of trying to make Math.max and Math.min semi-fast
      in the optimizing compilers with weird work-arounds support %_Arguments
      %_ArgumentsLength, we do provide the optimal code as native builtins
      instead and call it a day (which gives a nice performance boost on some
      benchmarks).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1641083003
      
      Cr-Commit-Position: refs/heads/master@{#33582}
      cb9b8010
  15. 22 Jan, 2016 1 commit
    • ishell's avatar
      Array length reduction should throw in strict mode if it can't delete an element. · ed2be747
      ishell authored
      When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
      
      Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
      
      This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
      
      BUG=v8:4267
      LOG=Y
      
      Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
      Cr-Commit-Position: refs/heads/master@{#33438}
      
      Review URL: https://codereview.chromium.org/1587073003
      
      Cr-Commit-Position: refs/heads/master@{#33461}
      ed2be747
  16. 21 Jan, 2016 3 commits
    • machenbach's avatar
      Revert of Array length reduction should throw in strict mode if it can't... · 575e90c1
      machenbach authored
      Revert of Array length reduction should throw in strict mode if it can't delete an element. (patchset #7 id:220001 of https://codereview.chromium.org/1587073003/ )
      
      Reason for revert:
      [Sheriff] Breaks layout tests. Please fix upstream.
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
      
      Original issue's description:
      > Array length reduction should throw in strict mode if it can't delete an element.
      >
      > When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
      >
      > Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
      >
      > This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
      >
      > BUG=v8:4267
      > LOG=Y
      >
      > Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
      > Cr-Commit-Position: refs/heads/master@{#33438}
      
      TBR=verwaest@chromium.org,ishell@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4267
      
      Review URL: https://codereview.chromium.org/1611313003
      
      Cr-Commit-Position: refs/heads/master@{#33444}
      575e90c1
    • ishell's avatar
      Array length reduction should throw in strict mode if it can't delete an element. · 1d3e837f
      ishell authored
      When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
      
      Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
      
      This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
      
      BUG=v8:4267
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1587073003
      
      Cr-Commit-Position: refs/heads/master@{#33438}
      1d3e837f
    • bmeurer's avatar
      [for-in] Sanitize for-in optimizations and fix bailout points. · f48bf12f
      bmeurer authored
      The PrepareId bailout location was used incorrectly in Crankshaft and,
      as it turns out, is not required anyway (once you do it right). Also
      there was some premature optimization going on with the CheckEnumCache
      (trying to load null from roots only once), plus we can be smarter about
      the null/undefined check anyway.
      
      The idea behind this changes is to prepare unification of the two
      different ForInPrepare implementations that we now have, with the end
      result being that we only use the new implementation that was recently
      added for the interpreter.
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1618613002
      
      Cr-Commit-Position: refs/heads/master@{#33426}
      f48bf12f
  17. 20 Jan, 2016 1 commit
  18. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored
      Adds a ForInPrepare Runtime function which returns a triple of
      cache_type, cache_array and cache_length.
      
      This requires adding support to CEntryStub to call runtime functions
      which return a ObjectTriple - a struct containing three Object*
      pointers. Also did some cleanup of the x64 CEntryStub to avoid
      replicated code.
      
      Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
      Runtime function with ForInPrepare in preparation for fixing deopt in
      BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1576093004
      
      Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  19. 13 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Number constructor similar to String constructor. · 322ffda3
      bmeurer authored
      Also migrate the Number constructor to a native builtin, using the
      same mechanism already used by the String constructor. Otherwise just
      parsing and compiling the Number constructor to optimized code already
      eats 2ms on desktop for no good reason, and the resulting optimized
      code is not even close to awesome.
      
      Drive-by-fix: Use correct context for the [[Construct]] case of the
      String constructor as well, and share some code with it.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1573243009
      
      Cr-Commit-Position: refs/heads/master@{#33265}
      322ffda3
  20. 30 Dec, 2015 1 commit
  21. 29 Dec, 2015 1 commit
  22. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      Cr-Commit-Position: refs/heads/master@{#33042}
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
      
      Reason for revert:
      Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
      
      Original issue's description:
      > [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
      >
      > According to the ES2015 specification, bound functions are exotic
      > objects, and thus don't need to be implemented as JSFunctions. So
      > we introduce a new JSBoundFunction type to represent bound functions
      > and make them optimizable. This already improves the performance of
      > calling or constructing bound functions by 10-100x depending on the
      > use case because we avoid the crazy dance between JavaScript and C++
      > that was implemented in v8natives.js previously.
      >
      > There's still room for improvement in the performance of actually
      > creating bound functions, which is also relevant in practice, but
      > we already have a plan how to accomplish that later.
      >
      > The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=chromium:535408, chromium:571299, v8:4629
      > LOG=n
      >
      > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      > Cr-Commit-Position: refs/heads/master@{#33042}
      
      TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:535408, chromium:571299, v8:4629
      
      Review URL: https://codereview.chromium.org/1552473002
      
      Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  23. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  24. 23 Dec, 2015 1 commit
  25. 04 Dec, 2015 3 commits
  26. 03 Dec, 2015 2 commits
  27. 27 Nov, 2015 4 commits
  28. 26 Nov, 2015 1 commit
  29. 25 Nov, 2015 2 commits