1. 07 Nov, 2016 2 commits
  2. 02 Sep, 2016 2 commits
  3. 01 Sep, 2016 1 commit
  4. 31 Aug, 2016 1 commit
  5. 26 Aug, 2016 1 commit
  6. 24 Aug, 2016 1 commit
  7. 16 Aug, 2016 1 commit
  8. 12 Aug, 2016 1 commit
  9. 11 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Utilize type information for alias analysis. · c0439051
      bmeurer authored
      If the intersection of the types of nodes a and b is empty, then there's
      no way that a and b could ever refer to the same object, so we can use
      that information for alias analysis.
      
      Drive-by-fix: Improve use of types to enable typed alias analysis to
      become more effective. Also fix an ASAN issue uncovered by this CL.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2237433003
      Cr-Commit-Position: refs/heads/master@{#38567}
      c0439051
  10. 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
  11. 05 Aug, 2016 3 commits
  12. 02 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce initial support for TypedArrays. · 66f2d3bd
      bmeurer authored
      This adds support for lowering keyed access to JSTypedArray objects to
      element loads and stores instead of IC calls. There's still a lot of
      room for improvement, but the improvements can be done incrementally
      later.
      
      We add a dedicated UnsafePointerAdd operator, which sits in the effect
      chain, and does the (GC invisible) computation of addresses that are
      potentially inside HeapObjects. Also there's now a dedicated Retain
      operator, which ensures that we retain a certain tagged value, which is
      necessary to ensure that we keep a JSArrayBuffer alive as long as we
      might still potentially access elements in its backing store.
      
      R=epertoso@chromium.org
      
      Review-Url: https://codereview.chromium.org/2203693002
      Cr-Commit-Position: refs/heads/master@{#38235}
      66f2d3bd
  13. 29 Jul, 2016 1 commit
    • 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
  14. 28 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Refactor the lowering of element/property accesses. · 1bce2790
      bmeurer authored
      Split the monster methods in JSNativeContextSpecialization into smaller
      ones, adding appropriate helpers. Improve the condition checking for
      strings and numbers using CheckString/CheckNumber when applicable. Also
      try to merge compatible PropertyAccessInfos, to avoid running into the
      polymorphic case whenever possible.
      
      Drive-by-fix: Don't try to resurrect dead nodes during LoadElimination.
      With the improve code generation for monomorphic loads, we seem to
      trigger the dead node resurrection.
      
      R=epertoso@chromium.org
      BUG=v8:4930,v8:5141
      
      Review-Url: https://codereview.chromium.org/2191823002
      Cr-Commit-Position: refs/heads/master@{#38127}
      1bce2790
  15. 25 Jul, 2016 1 commit
  16. 05 Jul, 2016 1 commit
    • 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
  17. 30 Jun, 2016 1 commit
  18. 29 Jun, 2016 1 commit
  19. 28 Jun, 2016 1 commit
  20. 18 May, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Turn common Guard operator into simplified TypeGuard. · c5a71f02
      bmeurer authored
      The type guard should never be used after the effect/control
      linearization pass, so making it a simplified operator better
      expresses the intended use. Also this way none of the common
      operators actually has any dependency on the type system.
      
      Drive-by-fix: Properly print the type parameter to a TypeGuard operator.
      
      BUG=chromium:612142
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/1994503002
      Cr-Commit-Position: refs/heads/master@{#36304}
      c5a71f02
  21. 02 May, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Extend the type fixup to LoadField as well. · c0e65ea8
      bmeurer authored
      For LoadElimination we must not replace LoadField nodes with other nodes
      whose types are not a subtype of the original LoadField type, as that
      breaks the verifier. We already fixed that earlier for store to load
      forwarding, but the fix didn't cover LoadField forwarding.
      
      This actually still generates the correct code even w/o the fix, but
      since recently fails due to stronger checking in representation
      selection. So this makes clusterfuzz happy again.
      
      R=mvstanton@chromium.org
      BUG=chromium:607899
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1934973002
      Cr-Commit-Position: refs/heads/master@{#35930}
      c0e65ea8
  22. 05 Apr, 2016 1 commit
    • jarin's avatar
      [turbofan] Restrict types in load elimination. · 4142bc6b
      jarin authored
      In simplified numbering, we make sanity checks based on types (e.g.,
      NumberSubtract should take numbers as inputs), but this can be
      violated if optimization passes make types less precise.
      
      In this CL, we fix load elimination to make sure that types are
      smaller in the store -> load elimination by taking an intersection
      of the load's type with the store value's type and inserting a guard
      with that type. Note that the load type comes from type feedback, so
      it can be disjoint from the stored value type (in that case, this
      must be dead code because the map chack for the load should prevent
      us from using the stored value).
      
      BUG=chromium:599412
      LOG=n
      
      Review URL: https://codereview.chromium.org/1857133003
      
      Cr-Commit-Position: refs/heads/master@{#35259}
      4142bc6b
  23. 23 Nov, 2015 1 commit
  24. 05 Jun, 2015 1 commit
  25. 29 Jan, 2015 1 commit
  26. 05 Dec, 2014 1 commit