1. 12 Aug, 2016 2 commits
    • ahaas's avatar
      Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and... · ce5a46b3
      ahaas authored
      Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. (patchset #3 id:40001 of https://codereview.chromium.org/2229243003/ )
      
      Reason for revert:
      There is a data race in the initialization of the Isolate::random_number_generator()
      
      Original issue's description:
      > [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject.
      >
      > This CL splits CodeGenerator::GenerateCode into two new functions:
      > AssembleCode and FinishCodeObject. AssembleCode does not access or
      > modify the JS heap, which means that AssembleCode can be executed on
      > background threads. FinishCodeObject allocates the generated code object
      > on the JS heap and therefore has to be executed on the main thread.
      >
      > Implementation details:
      > The GenerateCode function has been split just before out-of-line code is
      > assembled. The reason is that code stubs may be generated when
      > out-of-line code is assembled, which potentially allocates these code
      > stubs on the heap.
      >
      > - Parts of initialization of the CodeGenerator has been moved from the
      > constructor to an Initialize function so that we can instantiate an empty
      > CodeGenerator object in PipelineData.
      >
      > R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
      >
      > Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2
      > Cr-Commit-Position: refs/heads/master@{#38604}
      
      TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review-Url: https://codereview.chromium.org/2240523003
      Cr-Commit-Position: refs/heads/master@{#38605}
      ce5a46b3
    • ahaas's avatar
      [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. · 03058a21
      ahaas authored
      This CL splits CodeGenerator::GenerateCode into two new functions:
      AssembleCode and FinishCodeObject. AssembleCode does not access or
      modify the JS heap, which means that AssembleCode can be executed on
      background threads. FinishCodeObject allocates the generated code object
      on the JS heap and therefore has to be executed on the main thread.
      
      Implementation details:
      The GenerateCode function has been split just before out-of-line code is
      assembled. The reason is that code stubs may be generated when
      out-of-line code is assembled, which potentially allocates these code
      stubs on the heap.
      
      - Parts of initialization of the CodeGenerator has been moved from the
      constructor to an Initialize function so that we can instantiate an empty
      CodeGenerator object in PipelineData.
      
      R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2229243003
      Cr-Commit-Position: refs/heads/master@{#38604}
      03058a21
  2. 11 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add inlined Array.prototype.pop support. · b8f47504
      bmeurer authored
      This adds a very first version of inlined Array.prototype.pop into
      TurboFan optimized code. We currently limit the inlining to fast
      object or smi elements, until the unclear situation around hole NaNs
      is resolved and we have a clear semantics inside the compiler.
      
      It's also probably overly defensive in when it's safe to inline
      the call to Array.prototype.pop, but we can always extend that
      later once we have sufficient trust in the implementation and see
      an actual need to extend it.
      
      BUG=v8:2229,v8:3952,v8:5267
      R=epertoso@chromium.org
      
      Review-Url: https://codereview.chromium.org/2239703002
      Cr-Commit-Position: refs/heads/master@{#38578}
      b8f47504
  3. 09 Aug, 2016 1 commit
  4. 08 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add initial support for growing stores. · e6822a83
      bmeurer authored
      Introduce a dedicated MaybeGrowFastElements simplified operator, which
      tries to grow a fast elements backing store for a given element that
      should be added to an array/object. Use that to lower a growing keyed
      store to a sequence of
      
       1) check index is a valid array index,
       2) check stored value,
       3) maybe grow elements backing store (and deoptimize if it would
          normalize), and
       4) store the actual element.
      
      The actual growing is done by two dedicated GrowFastDoubleElements
      and GrowFastSmiOrObjectElements builtins, which are very similar to
      the GrowArrayElementsStub that is used by Crankshaft.
      
      Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements
      builtin, similar to the new growing builtins, so we don't need to
      inline the store+write barrier for the elements into all optimized
      code objects anymore.
      
      Also fix a bug in the OperationTyper for NumberSilenceNaN, which was
      triggered by this change.
      
      BUG=v8:5272
      
      Review-Url: https://codereview.chromium.org/2227493002
      Cr-Commit-Position: refs/heads/master@{#38418}
      e6822a83
  5. 05 Aug, 2016 3 commits
  6. 03 Aug, 2016 1 commit
  7. 01 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for accessor inlining. · 35a195e1
      bmeurer authored
      Allow inlining of getters and setters into TurboFan optimized code.
      This just adds the basic machinery required to essentially inline
      the setter and getter dispatch code for the (keyed) load/store ICs.
      There'll be follow up CLs to also actually inline some of the interesting
      accessor functions itself, like the byteLength and friends for the
      TypedArrays.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2198473002
      Cr-Commit-Position: refs/heads/master@{#38192}
      35a195e1
  8. 29 Jul, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Introduce a dedicated CheckMaps simplified operator. · 8201579e
      bmeurer authored
      So far we always create explicit control flow for map checks during
      JSNativeContextSpecialization, or in the monomorphic case we used a
      CheckIf combined with a map comparison. In either case we cannot
      currently effectively utilize the map check information during load
      elimination to optimize (polymorphic) map checks and elements kind
      transitions.
      
      With the introduction of CheckMaps, we can now start optimizing map
      checks in a more effective fashion. This CL doesn't change anything
      in that direction yet, but merely changes the fundamental mechanism.
      
      This also removes the stable map optimization from the Typer, where
      it was always a bit odd, and puts it into the typed lowering and
      the native context specialization instead.
      
      R=epertoso@chromium.org
      BUG=v8:4930,v8:5141
      
      Review-Url: https://codereview.chromium.org/2196653002
      Cr-Commit-Position: refs/heads/master@{#38166}
      8201579e
    • bmeurer's avatar
      [turbofan] Run JSIntrinsicLowering together with inlining. · ad3cac72
      bmeurer authored
      R=mvstanton@chromium.org
      
      Review-Url: https://codereview.chromium.org/2195623002
      Cr-Commit-Position: refs/heads/master@{#38160}
      ad3cac72
  9. 27 Jul, 2016 3 commits
    • bmeurer's avatar
      [turbofan] Also eliminate branches during load elimination. · 14e2bcda
      bmeurer authored
      Also run the BranchElimination (plus CommonOperatorReducer and the
      DeadCodeElimination) during the load elimination phase, so we can
      elminate some Phi nodes early on that would otherwise confuse the
      truncation analysis and/or representation selection, i.e. if there's a
      branch that is never taken, that would yield undefined, we'd have to
      choose tagged representation for the Phi, even if the always taken
      branch yields an integer.
      
      R=epertoso@chromium.org
      BUG=v8:4930,v8:5141
      
      Review-Url: https://codereview.chromium.org/2190543002
      Cr-Commit-Position: refs/heads/master@{#38088}
      14e2bcda
    • mstarzinger's avatar
      [interpreter] Implement OSR graph construction from bytecode. · 1314406c
      mstarzinger authored
      This implements graph construction for entry via on-stack replacement
      within the {BytecodeGraphBuilder}. Entry points are at loop headers
      similar to previous OSR implementations. All interpreter registers are
      addressable via {OsrValue} nodes in the graph. Currently we rely on
      {OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
      targets of back edges).
      
      R=jarin@chromium.org
      BUG=v8:4764
      
      Review-Url: https://codereview.chromium.org/2171083004
      Cr-Commit-Position: refs/heads/master@{#38083}
      1314406c
    • jarin's avatar
      [turbofan] Induction variable bound analysis. · 398a1143
      jarin authored
      The new phase will detect loop variable, infer bounds and bake them into
      the type.
      
      Review-Url: https://codereview.chromium.org/2164263003
      Cr-Commit-Position: refs/heads/master@{#38077}
      398a1143
  10. 26 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Run JSGenericLowering as separate phase. · bec00d24
      bmeurer authored
      This works around the problem that the lowering for JSStackCheck doesn't
      play well with effect chain based state tracking, because it doesn't
      report the correct changes (we will address this with a better handling
      of stack checks soon).
      
      It also allows us to run the EarlyOptimizationPhase concurrently, which
      doesn't need to access the heap or generate code stubs.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2183033002
      Cr-Commit-Position: refs/heads/master@{#38049}
      bec00d24
  11. 25 Jul, 2016 3 commits
  12. 22 Jul, 2016 2 commits
  13. 15 Jul, 2016 1 commit
  14. 14 Jul, 2016 3 commits
  15. 12 Jul, 2016 1 commit
  16. 11 Jul, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Remove dead code from SimplifiedLowering. · 42c29648
      bmeurer authored
      This is follow-up cleanup for the flags that are no longer used inside
      SimplifiedLowering.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2132403002
      Cr-Commit-Position: refs/heads/master@{#37652}
      42c29648
    • bmeurer's avatar
      [turbofan] Eliminate a few redundant bounds checks. · 4f976328
      bmeurer authored
      Usually loops run from 0 to some array length l, which means the
      induction variable i will probably have type Unsigned32, just like
      the length l. The CheckBounds operation lowers to an Uint32LessThan
      comparison, so if we also lower the user level i < l comparison to
      Uint32LessThan (whenever possible), we get some bounds check elimination
      for free (via value numbering plus branch condition elimination).
      
      This merges the branch condition elimination phase with the late
      optimization phase to make this magic happen.
      
      R=jarin@chromium.org
      BUG=v8:4930,v8:5141
      
      Review-Url: https://codereview.chromium.org/2135123002
      Cr-Commit-Position: refs/heads/master@{#37629}
      4f976328
  17. 05 Jul, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Initial version of the new LoadElimination. · d70dc1ac
      bmeurer authored
      This adds a new optimization phase to the TurboFan pipeline, which walks
      over the effect chain and tries to eliminate redundant loads (and even
      some stores) of object fields. We currently ignore element access, but
      that will probably need to be handled as well at some point. We also
      don't have any special treatment to properly track object maps, which is
      also on the list of things that will happen afterwards.
      
      The implementation is pretty simple currently, and probably way to
      inefficient. It's meant to be a proof-of-concept to iterate on.
      
      R=jarin@chromium.org
      BUG=v8:4930,v8:5141
      
      Review-Url: https://codereview.chromium.org/2120253002
      Cr-Commit-Position: refs/heads/master@{#37528}
      d70dc1ac
    • bmeurer's avatar
      [turbofan] Run value numbering as part of typed lowering. · b18b3877
      bmeurer authored
      We can already benefit from value numbering (pure) nodes at this point
      in the graph, because it makes some later passes more efficient and
      reduces the graph size early.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2125613002
      Cr-Commit-Position: refs/heads/master@{#37523}
      b18b3877
  18. 29 Jun, 2016 1 commit
  19. 27 Jun, 2016 1 commit
  20. 23 Jun, 2016 2 commits
  21. 22 Jun, 2016 1 commit
  22. 21 Jun, 2016 1 commit
  23. 13 Jun, 2016 2 commits
    • mvstanton's avatar
      Machine-readable TurboFan compiler statistics · 14732265
      mvstanton authored
      We'd like to track performance metrics in an automated way. This CL introduces
      --turbo-stats-nvp which exposes --turbo-stats information in {"name"=value} pair
      format.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2053383002
      Cr-Commit-Position: refs/heads/master@{#36919}
      14732265
    • mtrofin's avatar
      [turbofan] Retiring Greedy Allocator · 8e1ccba3
      mtrofin authored
      We were able to achieve our goals for register allocation independent of
      the allocation algorithm. Performance data so far is inconclusive re. the
      value of the Greedy algorithm, compared to the particular Linear Scan
      implementation we're currently using, and the performance measurement
      techniques we currently use are too imprecise to help with this matter.
      
      Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
      cost of adding aliasing support). Once we improve benchmarking stability,
      and establish a suite sensitive enough for codegen improvement studies,
      we may revive the algorithm, should the need arise.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2060673002
      Cr-Commit-Position: refs/heads/master@{#36912}
      8e1ccba3
  24. 07 Jun, 2016 1 commit
  25. 06 Jun, 2016 1 commit