1. 17 Jul, 2019 1 commit
  2. 24 May, 2019 1 commit
  3. 29 Mar, 2019 1 commit
  4. 13 Feb, 2019 1 commit
  5. 02 Jan, 2019 1 commit
  6. 15 Oct, 2018 1 commit
  7. 25 Sep, 2018 1 commit
  8. 23 Jul, 2018 1 commit
  9. 07 Jun, 2018 1 commit
  10. 08 May, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Optimize array destructuring · 3fe7d698
      Jaroslav Sevcik authored
      This CL introduces type narrowing and constant folding reducers
      to constant fold code that comes out of inlined destructuring
      of arrays. In particular, array iterator introduces code that
      contains a phi of a temporary array that blocks escape analysis.
      The phi comes from conditional that can be evaluated statically
      (i.e., constant folded), so with better constant folding we
      allow escape analysis to get rid of the temporary array.
      
      On a quick micro-benchmark below, we see more than 6x improvement.
      This is close to the hand-optimized version - if we replace
      body of f with 'return b + a', we get 220ms (versus 218ms with
      destructuring).
      
      function f(a, b) {
        [b, a] = [a, b];
        return a + b;
      }
      
      function sum(count) {
        let s = 0;
        for (let i = 0; i < count; i++) {
          s += f(1, 2);
        }
        return s;
      }
      
      // Warm up
      sum(1e5); sum(1e5);
      console.time("destructure array");
      sum(1e8);
      console.timeEnd("destructure array");
      
      console.timeEnd: destructure array, 213.526000
      
      console.timeEnd: destructure array, 1503.537000
      
      Bug: v8:7728
      Change-Id: Ib7aec1d5897989e6adb1af1eddd516d8b3866db5
      Reviewed-on: https://chromium-review.googlesource.com/1047672Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53048}
      3fe7d698
  11. 28 Apr, 2018 1 commit
  12. 09 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Utilize the fact that empty string is canonicalized. · cd9724d4
      bmeurer authored
      Since the empty string is canonical HeapObject now, we can use
      this fact to optimize
      
        - strict equality comparisons with the empty string to a
          simple ReferenceEqual operation, and
        - optimize ToBoolean to avoid instance type checks completely.
      
      Drive-by-fix: Allow InternalizedString for Type::HeapConstant
      in the type system. This is safe, since InternalizedStrings
      can be compared to other heap constants by reference (except
      for non-InternalizedStrings, which are excluded from the
      HeapConstant type).
      
      BUG=v8:5267
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2681273002
      Cr-Commit-Position: refs/heads/master@{#43050}
      cd9724d4
  13. 02 Nov, 2016 1 commit
  14. 17 Oct, 2016 1 commit
  15. 29 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove the unused asm.js types from TypeCache. · f5a37d13
      bmeurer authored
      For asm.js we now have a dedicated AsmTyper, that uses it's own type
      system (which is tailored towards asm.js), and so we don't need the
      special asm.js types anymore in the TypeCache. This also moves the
      TypeCache into the src/compiler directory, because it doesn't make
      sense to use outside anyways.
      
      TBR=ahaas@chromium.org
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2289573002
      Cr-Commit-Position: refs/heads/master@{#38964}
      f5a37d13
  16. 03 Aug, 2016 1 commit
  17. 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
  18. 27 Jul, 2016 1 commit
  19. 21 Jul, 2016 1 commit
  20. 22 Jun, 2016 1 commit
  21. 02 Feb, 2016 1 commit
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      jarin authored
      This CL removes the Config templatization from the types. It is not
      necessary anymore, after the HeapTypes have been removed.
      
      The CL also changes the type hierarchy - the specific type kinds are
      not inner classes of the Type class and they do not inherit from Type.
      This is partly because it seems impossible to make this work without
      templates. Instead, a new TypeBase class is introduced and all the
      structural (i.e., non-bitset) types inherit from it.
      
      The bitset type still requires the bit-munging hack and some nasty
      reinterpret-casts to pretend bitsets are of type Type*. Additionally,
      there is now the same hack for TypeBase - all pointers to the sub-types
      of TypeBase are reinterpret-casted to Type*. This is to keep the type
      constructors in inline method definitions (although it is unclear how
      much that actually buys us).
      
      In future, we would like to move to a model where we encapsulate Type*
      into a class (or possibly use Type where we used to use Type*). This
      would loosen the coupling between bitset size and pointer size, and
      eventually we would be able to have more bits.
      
      TBR=bradnelson@chromium.org
      
      Review URL: https://codereview.chromium.org/1655833002
      
      Cr-Commit-Position: refs/heads/master@{#33656}
      ef35f11c
  22. 24 Nov, 2015 1 commit
  23. 28 Oct, 2015 1 commit
  24. 26 Oct, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Properly type field access to stable heap object maps. · 44b9122d
      bmeurer authored
      Introduce new typing rules for LoadField[Map], which try to take into
      account stable map information if the object either has type Constant or
      type Class. If the map of the object is stable but can transition we
      have to introduce a code dependency in the Typer to make sure that the
      information (the Constant type we infer for LoadField[Map]) is valid
      (and stays valid).
      
      This also settles the policy for depending on map stability: The
      definition can introduce any number of maps, without having to pay
      attention to stability (i.e. you can always use Type::Class to introduce
      a map that is propagated along the value edges), and the use site is
      responsible for checking that the type information is valid before using
      it. I.e. if you use stable map information, you'll have to add a
      stability dependency (or make sure the map cannot transition).
      
      Drive-by-improvement: Add ReferenceEqualTyper which takes input types
      into account for improved constant folding.
      
      Drive-by-fix: Apply policy mentioned above to JSNativeContextSpecialization.
      
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1410953006
      
      Cr-Commit-Position: refs/heads/master@{#31567}
      44b9122d
  25. 26 Aug, 2015 1 commit
  26. 30 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Remove unused constructor function matching from typer. · 722e2e2b
      bmeurer authored
      This optimization never triggers currently, and is inherently native
      context dependent for no real reason (for example it will not properly
      detect those constructors in the case of cross native context inlining),
      plus it is slow and awkward.  In case we really need this functionality
      at some point, we should find a way to make it work with the builtin
      function id mechanism that is already in place to match other builtins.
      
      R=jarin@chromium.org,rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1221683006
      
      Cr-Commit-Position: refs/heads/master@{#29365}
      722e2e2b
  27. 24 Jun, 2015 2 commits
  28. 22 Jun, 2015 1 commit
  29. 17 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Fix life time and use of the Typer. · a4f06027
      bmeurer authored
      Currently the Typer is installed on the Graph, no matter if we actually
      use the types or not (read: even in the generic pipeline). Also the
      Typer tries hard to eagerly type nodes during graph building, which
      takes time, just to remove those types later again, and retype
      everything from scratch. Plus this is inconsistent, since it only
      applies to the outermost graph, not the inlined graphs (which are
      eagerly typed once the nodes are copied). So in summary, what's
      currently implemented is neither useful nor well defined, so for now we
      stick to the full typing approach until a proper design for eager typing
      is available that will actually benefit us.
      
      R=rossberg@chromium.org,mstarzinger@chromium.org,jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1192553002
      
      Cr-Commit-Position: refs/heads/master@{#29086}
      a4f06027
  30. 19 Mar, 2015 1 commit
  31. 09 Feb, 2015 1 commit
  32. 28 Jan, 2015 1 commit
  33. 23 Jan, 2015 1 commit
    • danno's avatar
      Remove the dependency of Zone on Isolate · c7b09aac
      danno authored
      Along the way:
      - Thread isolate parameter explicitly through code that used to
        rely on getting it from the zone.
      - Canonicalize the parameter position of isolate and zone for
        affected code
      - Change Hydrogen New<> instruction templates to automatically
        pass isolate
      
      R=mstarzinger@chromium.org
      LOG=N
      
      Review URL: https://codereview.chromium.org/868883002
      
      Cr-Commit-Position: refs/heads/master@{#26252}
      c7b09aac
  34. 22 Dec, 2014 1 commit
  35. 11 Dec, 2014 1 commit
  36. 08 Dec, 2014 1 commit
  37. 03 Dec, 2014 3 commits