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. 28 Apr, 2016 3 commits
  3. 27 Apr, 2016 1 commit
  4. 25 Apr, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Add baseline tier to compilation pipeline. · 3fc0224c
      mstarzinger authored
      This adds a baseline tier to the compilation pipeline. Currently this
      tier is used to model a path from the interpreter to optimized code via
      full-codegen code (to ensure sufficient type feedback). Switching from
      the unoptimized tier to the baseline tier is limited to happen only when
      there are no activations of the given function on the stack.
      
      R=rmcilroy@chromium.org,bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1903273004
      
      Cr-Commit-Position: refs/heads/master@{#35757}
      3fc0224c
  5. 22 Apr, 2016 1 commit
  6. 19 Apr, 2016 1 commit
  7. 18 Apr, 2016 2 commits
  8. 15 Apr, 2016 1 commit
  9. 14 Apr, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Make dispatch table point to code entry instead of code objects. · 0c05e02f
      rmcilroy authored
      Modifies Ignition to store code entry addresses in the dispatch table
      rather than code objects. This allows the interpreter to avoid
      calculating the code entry address from the code object on every
      dispatch and provides a ~5-7% performance improvement on Octane with
      Ignition.
      
      This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
      tail call dispatch using these code addresses. It also adds a Dispatch
      linkage creator (distinct from the stub linkage type used previously) to
      allow targetting a code address target (which will diverge further from
      the stub linkage type when we remove the context machine register in
      Ignition).
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1882073002
      
      Cr-Commit-Position: refs/heads/master@{#35480}
      0c05e02f
  10. 13 Apr, 2016 1 commit
  11. 12 Apr, 2016 1 commit
  12. 11 Apr, 2016 2 commits
  13. 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
  14. 29 Mar, 2016 1 commit
  15. 22 Mar, 2016 1 commit
  16. 21 Mar, 2016 1 commit
    • mstarzinger's avatar
      [es6] Faster implementation of OrdinaryHasInstance. · b6419fa2
      mstarzinger authored
      Now implemented as a builtin that delegates to the InstanceOfStub. That
      stub was parameterized to fallback to either Runtime_InstanceOf or to
      Runtime_OrdinaryHasInstance depending on the --harmony-instanceof flag.
      Once the feature stabilizes and the flag is no longer needed, we can get
      rid of this parameterization again.
      
      R=bmeurer@chromium.org
      BUG=v8:4447
      LOG=n
      
      Review URL: https://codereview.chromium.org/1819813002
      
      Cr-Commit-Position: refs/heads/master@{#34959}
      b6419fa2
  17. 10 Mar, 2016 1 commit
  18. 08 Mar, 2016 2 commits
    • mstarzinger's avatar
      [compiler] Remove support for concurrent OSR. · 26692242
      mstarzinger authored
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1773593002
      
      Cr-Commit-Position: refs/heads/master@{#34572}
      26692242
    • 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
  19. 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
  20. 03 Mar, 2016 1 commit
  21. 24 Feb, 2016 2 commits
    • mythria's avatar
      Revert of [Interpreter] Implements calls through CallICStub in the... · eb358178
      mythria authored
      Revert of [Interpreter] Implements calls through CallICStub in the interpreter. (patchset #15 id:270001 of https://codereview.chromium.org/1688283003/ )
      
      Reason for revert:
      It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code  related to the type feedback vector into the builtin.
      
      Original issue's description:
      > [Interpreter] Implements calls through CallICStub in the interpreter.
      >
      > Calls are implemented through CallICStub to collect type feedback. Adds
      > a new builtin called InterpreterPushArgsAndCallIC that pushes the
      > arguments onto stack and calls CallICStub.
      >
      > Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
      > go through CallICStub.
      >
      > MIPS port contributed by balazs.kilvady.
      >
      > BUG=v8:4280, v8:4680
      > LOG=N
      >
      > Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
      > Cr-Commit-Position: refs/heads/master@{#34244}
      
      TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280, v8:4680
      
      Review URL: https://codereview.chromium.org/1731253003
      
      Cr-Commit-Position: refs/heads/master@{#34252}
      eb358178
    • mythria's avatar
      [Interpreter] Implements calls through CallICStub in the interpreter. · 20362a22
      mythria authored
      Calls are implemented through CallICStub to collect type feedback. Adds
      a new builtin called InterpreterPushArgsAndCallIC that pushes the
      arguments onto stack and calls CallICStub.
      
      Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
      go through CallICStub.
      
      MIPS port contributed by balazs.kilvady.
      
      BUG=v8:4280, v8:4680
      LOG=N
      
      Review URL: https://codereview.chromium.org/1688283003
      
      Cr-Commit-Position: refs/heads/master@{#34244}
      20362a22
  22. 22 Feb, 2016 1 commit
  23. 19 Feb, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Enable runtime profiler support for Ignition. · b62bf1e6
      rmcilroy authored
      Adds a profiling counter to each BytecodeArray object, and adds
      code to Jump and Return bytecode handlers to update this
      counter by the size of the jump or the distance from the return
      to the start of the function. This is more accurate than fullcodegen's
      approach since it takes forward jumps into account as well as back-edges.
      
      Modifies RuntimeProfiler to track ticks for interpreted frames.
      Currently we use the SharedFunctionInfo::profiler_ticks() instead
      of adding another to tick field to avoid adding another field to
      BytecodeArray since SharedFunctionInfo::profiler_ticks() is only
      used by Crankshaft otherwise so we shouldn't need both for
      
      BUG=v8:4689
      LOG=N
      
      Review URL: https://codereview.chromium.org/1707693003
      
      Cr-Commit-Position: refs/heads/master@{#34166}
      b62bf1e6
    • 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
  24. 18 Feb, 2016 1 commit
  25. 17 Feb, 2016 1 commit
  26. 16 Feb, 2016 1 commit
  27. 12 Feb, 2016 1 commit
    • bmeurer's avatar
      [runtime] Introduce FastNewStrictArgumentsStub to optimize strict arguments. · 09d84535
      bmeurer authored
      The FastNewStrictArgumentsStub is very similar to the recently added
      FastNewRestParameterStub, it's actually almost a copy of it, except that
      it doesn't have the fast case we have for the empty rest parameter. This
      patch improves strict arguments in TurboFan and fullcodegen by up to 10x
      compared to the previous version.
      
      Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
      for the in-object properties instead of having them as constants in the
      Heap class.
      
      Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
      interpreter to avoid the runtime call overhead for strict arguments
      and rest parameter creation.
      
      R=jarin@chromium.org
      TBR=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1693513002
      
      Cr-Commit-Position: refs/heads/master@{#33925}
      09d84535
  28. 11 Feb, 2016 1 commit
  29. 10 Feb, 2016 1 commit
    • mvstanton's avatar
      Preserve argument count for calls. · 5de27c34
      mvstanton authored
      Calls use registers for target, new_target and argument count.
      We don't always respect argument count. It didn't bite us in the past
      because the code paths where we clobbered it never used it, though
      in future it could be an issue.
      
      BUG=
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1683593003
      
      Cr-Commit-Position: refs/heads/master@{#33865}
      5de27c34
  30. 08 Feb, 2016 2 commits
    • mstarzinger's avatar
      Remove --stop-at flag from several backends. · 664110f8
      mstarzinger authored
      The flag in question is a debug-only flag supported by full-codegen and
      Crankshaft only. In it's current form there are some unresolved issues:
      - The flag is defeated by inlining in Crankshaft.
      - The flag is not supported by TurboFan.
      - The flag is not supported by Ignition.
      
      Instead of addressing the above issues and increasing maintenance cost
      for all backends and also given the "slim" test coverage, this CL fully
      removes the support from all backends.
      
      R=bmeurer@chromium.org,jkummerow@chromium.org
      
      Review URL: https://codereview.chromium.org/1676263002
      
      Cr-Commit-Position: refs/heads/master@{#33817}
      664110f8
    • verwaest's avatar
      Mark maps having a hidden prototype rather than maps of hidden prototypes. · d2503c4d
      verwaest authored
      Generally we only care whether the next object is a hidden prototype.
      It's simpler to check whether the current object has a hidden prototype
      instead of walking to the next prototype and checking its map.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1675223002
      
      Cr-Commit-Position: refs/heads/master@{#33816}
      d2503c4d
  31. 06 Feb, 2016 1 commit
    • ishell's avatar
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the... · da213b6e
      ishell authored
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.
      
      Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
      When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
      ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
      
      The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
      
      BUG=chromium:579009
      LOG=Y
      
      Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
      Cr-Commit-Position: refs/heads/master@{#33674}
      
      Review URL: https://codereview.chromium.org/1642223003
      
      Cr-Commit-Position: refs/heads/master@{#33798}
      da213b6e
  32. 05 Feb, 2016 1 commit