1. 22 May, 2017 1 commit
  2. 17 May, 2017 1 commit
  3. 15 May, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Properly merge compatible field access infos. · 130d7dc3
      bmeurer authored
      For a polymorphic access to o.x we would only merge it into a single
      PropertyAccessInfo so far, if x is at the same offset in all maps and
      the property index of x (in the descriptor arrays) is the same. But that
      doesn't matter for code generation and blocks optimizations even.
      
      BUG=v8:6278,v8:6344,v8:6396
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2883883002
      Cr-Commit-Position: refs/heads/master@{#45294}
      130d7dc3
  4. 09 May, 2017 1 commit
  5. 28 Apr, 2017 1 commit
  6. 25 Apr, 2017 2 commits
  7. 24 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Consolidate compatible element loads. · d853b238
      bmeurer authored
      This changes behavior of TurboFan to match the behavior of Crankshaft
      when it comes to polymorphic loads of similar elements kind (i.e. all
      tagged or all double), where we should use the "worst case" code without
      a transition. This is often much faster than transitioning the elements
      to the worst case first, trading a TransitionElementsKind for a CheckMaps
      and avoiding mutation of the array.
      
      This is beneficial for various crypto benchmarks, which don't need to
      pay the cost for TransitionElementsKind now.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2836943003
      Cr-Commit-Position: refs/heads/master@{#44815}
      d853b238
  8. 21 Apr, 2017 1 commit
  9. 10 Apr, 2017 1 commit
  10. 08 Apr, 2017 1 commit
  11. 07 Apr, 2017 1 commit
  12. 28 Mar, 2017 1 commit
  13. 14 Mar, 2017 1 commit
  14. 20 Feb, 2017 1 commit
  15. 10 Feb, 2017 1 commit
  16. 23 Jan, 2017 1 commit
  17. 20 Jan, 2017 1 commit
    • franzih's avatar
      [runtime] Allocate space for computed property names. · 399f36b5
      franzih authored
      Allocate space in the backing store for computed property names.
      
      The property backing store was pre-allocated for the constant
      properties up to the first non-constant (computed name) property.
      To use lowering for storing data properties in literals
      with computed property names effectively, a fast store is needed, i.e.,
      available space in the property backing store for properties
      with computed names.
      
      backing_store_size is the number of all properties (including
      computed names, but without __proto__)
      that is calculated in the ast and passed to the runtime function that allocates
      the property backing store. backing_store_size and
      constant_properties constitute a BoilerplateDescription.
      
      backing_store_size might be slightly too high because computed names
      can evaluate to the same name, but that should be a rare
      case so over-allocating is OK.
      
      If a property is __proto__, we don't store it as a regular
      property, because the map changes. Keep track of
      has_seen_proto in the parser to calculate the
      backing store size correctly.
      
      BUG=v8:5625
      
      Review-Url: https://codereview.chromium.org/2632503003
      Cr-Commit-Position: refs/heads/master@{#42576}
      399f36b5
  18. 16 Jan, 2017 1 commit
  19. 13 Jan, 2017 1 commit
  20. 12 Jan, 2017 1 commit
  21. 11 Jan, 2017 1 commit
  22. 10 Jan, 2017 1 commit
  23. 21 Nov, 2016 2 commits
  24. 14 Nov, 2016 1 commit
  25. 10 Nov, 2016 1 commit
  26. 09 Nov, 2016 1 commit
  27. 31 Oct, 2016 1 commit
  28. 12 Oct, 2016 1 commit
  29. 22 Sep, 2016 1 commit
  30. 31 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove remaining uses of Class type from the compiler. · 2b938990
      bmeurer authored
      We (mis)used Type::Class to track stable field maps in the past. But
      that always more or less unsupport and wrong for various reasons, mostly
      because the class types do not really present static information and
      thus it is possible to violate fundamental assumptions of the type
      system (i.e. intersecting class types and other types produces
      "interesting" results).
      
      Now it is possible to finally nuke the class types completely and thus
      simplify (and ideally correctify) the type system further.
      
      Note to performance sheriff: We do expect to see some performance
      regressions from this change. This is because we do not yet have a sane
      replacement mechanism to track known field maps and utilize them during
      LoadElimination. This will be accomplished in a follow up CL.
      
      BUG=v8:5270,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2293343002
      Cr-Commit-Position: refs/heads/master@{#39031}
      2b938990
  31. 30 Aug, 2016 1 commit
  32. 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
  33. 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
  34. 05 Aug, 2016 1 commit
  35. 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
  36. 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
  37. 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
  38. 14 Jun, 2016 1 commit