1. 03 Apr, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Remove unreachable successor basic blocks from schedule. · 4a2ef63c
      Ross McIlroy authored
      Effect-control-linearizer will update a basic block to connect it
      directly to the end node if it has an Unreachable node. Usually the
      block would already have been connected directly to end (via a Throw
      node) already, however in some cases it can be connected indirectly
      (via a branch, where both end in a throw node).
      
      If this happens, and the Effect-control-linearizer is maintaining the
      schedule (e.g., for TurboProp), it will cause the end block to have
      unreachable predecessor blocks, which can cause issues with the
      register allocator.
      
      To fix this, have the BasicBlockUpdater remove all successor blocks
      from the schedule, when they become Unreachable. Also add some tests
      to cover this in effect-control-linearizer-unittests.
      
      BUG=v8:10332,v8:9684
      
      Change-Id: Ibce140e6d1f61751a86247e6f8c36075723a1e55
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120537
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66994}
      4a2ef63c
  2. 10 Dec, 2019 1 commit
  3. 01 Jul, 2019 1 commit
  4. 24 May, 2019 1 commit
  5. 03 May, 2019 1 commit
  6. 02 May, 2019 2 commits
  7. 18 Mar, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Unify code that determines a JSCreate's map · d9221717
      Georg Neis authored
      There were four places where we did essentially the same steps in
      order to extract the initial map for inlining a JSCreate operation.
      This CL creates a function on NodeProperties for this task.
      
      As a side effect, this fixes a bug in ReduceJSCreateArray, where
      has_initial_map could get called when it wasn't permissible to do so.
      
      Notes: For simplicity, in one or two places where we used to get the
      target/newtarget constants from the types we now get them from
      HeapConstant nodes.
      
      Cosmetic change: rename "receiver_map" to the more accurate
      "root_map" in JSNativeContextSpecialization::ExtractReceiverMaps.
      
      Bug: chromium:939316
      Change-Id: I8fd9eb50993be3d839ab9b18eeea28184c53eabf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528435
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60301}
      d9221717
  8. 08 Feb, 2019 1 commit
  9. 12 Oct, 2018 1 commit
  10. 15 Jun, 2018 1 commit
  11. 28 Apr, 2018 1 commit
  12. 23 Feb, 2018 3 commits
  13. 04 Jan, 2018 1 commit
  14. 29 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Unify CanBePrimitive and NeedsConvertReceiver. · 9fb39c6b
      Benedikt Meurer authored
      The two helper functions CanBePrimitive and NeedsConvertReceiver did
      essentially the same, just in a slightly different way, and both weren't
      really robust wrt. to the list of JSConstruct* and JSCreate* operators
      that they were handling. There's now a single helper in the
      NodeProperties and a couple of extra macro lists to keep this list up
      to date more easily.
      
      Drive-by-fix: Also moved the CanBeNullOrUndefined helper to the
      NodeProperties class.
      
      Bug: v8:5267, v8:7109
      Change-Id: Ibbf387040e3f424ee224c53fac15c2b3207b1926
      Reviewed-on: https://chromium-review.googlesource.com/793734Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49695}
      9fb39c6b
  15. 27 Oct, 2017 1 commit
  16. 07 Sep, 2017 1 commit
  17. 31 Jul, 2017 1 commit
  18. 28 Jul, 2017 4 commits
  19. 10 Jul, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Initial optimization of Map.prototype.(get|has) in Turbofan. · aba708a1
      Jaroslav Sevcik authored
      This introduces a new builtin (MapLookupHashIndex) and uses it
      in Turbofan to compute Map.p.get and Map.p.has.
      
      I have also refactored the existing CSA builtins for Map.p.get and 
      Map.p.has to use the new builtin under the hood.
      
      The code for the lookup has been also improved.
      - Specialized lookups for smis, strings, heap numbers and everything else.
        - the advantage is that we can use fast equalities for the lookup.
        - strings can likely be optimized further if we care about the 
          internalized string fast case.
      - Instead of a call to runtime to get the hash code, we now call C directly.
      
      In the Turbofan implementation itself, there are no special optimizations yet.
      The next step is to teach load elimination to reuse the indexes from
      previous calls of MapLookupHashIndex. 
      
      BUG=v8:6410
      
      Change-Id: I0b1a70493eb031d444e51002f6b2cc1f30ea2b68
      Reviewed-on: https://chromium-review.googlesource.com/560169Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46510}
      aba708a1
  20. 10 May, 2017 1 commit
  21. 04 May, 2017 1 commit
    • neis's avatar
      [compiler][modules] Constant-fold loads of module cells. · 24d78901
      neis authored
      1. Generalize context specialization such that the provided context
         can be any outer context of the function, not necessarily the
         immediate outer context.
      
      2. Based on this: if function specialization is disabled, then
         specialize for the module context if there is one.
      
      3. Extend typed lowering of module loads and stores such that if
         the operand is a Module constant, we constant-fold the cell load.
         That is, a JSLoadModule with a Module HeapConstant input becomes
         a LoadField with a Cell HeapConstant input, and similarly for
         JSStoreModule.
      
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2841613002
      Cr-Commit-Position: refs/heads/master@{#45083}
      24d78901
  22. 12 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Use unreliable LOAD_IC feedback for Array.prototype.push. · 1fceaf9f
      bmeurer authored
      Add the notion of reliable vs. unreliable receiver map information to
      the NodeProperties::InferReceiverMaps machinery. The information is
      considered reliable here if the maps are known to be valid based on the
      effect chain, and unreliable if there was a side-effect in between that
      might have changed the receiver map.
      
      Use this unreliable information for Array.prototype.push, guarded by
      either stability dependencies or map checks, which might present a
      potential deoptimization loop, which is very unlikely, but still needs
      fixing in the future. This is important to optimize calls to push even
      in cases like this
      
        array.push(something.func());
      
      where we have a side-effect (the call to something.func) between the
      load of array.push and the actual call.
      
      R=jarin@chromium.org
      BUG=v8:5267,v8:6241
      
      Review-Url: https://codereview.chromium.org/2812233002
      Cr-Commit-Position: refs/heads/master@{#44595}
      1fceaf9f
  23. 02 Mar, 2017 1 commit
  24. 20 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Unify NodeProperties::InferReceiverMaps. · fc331225
      bmeurer authored
      Unify the three different implementations of InferReceiverMaps, which
      were basically copy&paste with slightly different optimizations applied
      later into a single NodeProperties::InferReceiverMaps helper, which also
      returns a ZoneHandleSet of maps, rather than only a single map.
      
      BUG=v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2703133003
      Cr-Commit-Position: refs/heads/master@{#43318}
      fc331225
  25. 18 Jan, 2017 1 commit
  26. 13 Jan, 2017 1 commit
    • neis's avatar
      [compiler] Generalize JSContextSpecialization. · fd8cebb1
      neis authored
      With this CL, context loads and stores are "strengthened" by reducing
      the incoming context chain and decreasing the depth accordingly,
      whenever possible.  This enables more opportunities for specialization
      and will let us easily add module context specialization later.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2559173003
      Cr-Commit-Position: refs/heads/master@{#42334}
      fd8cebb1
  27. 17 Oct, 2016 1 commit
  28. 10 Oct, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Enforce native context specialization. · f6bd23f2
      bmeurer authored
      There were once plans to generate cross-context code with TurboFan,
      however that doesn't fit into the model anymore, and so all of this
      is essentially dead untested code (and thus most likely already broken
      in subtle ways). With this mode still in place it would also be a lot
      harder to make inlining based on SharedFunctionInfo work.
      
      BUG=v8:2206,v8:5499
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2406803002
      Cr-Commit-Position: refs/heads/master@{#40109}
      f6bd23f2
  29. 05 Sep, 2016 1 commit
  30. 03 Aug, 2016 1 commit
  31. 02 Jun, 2016 1 commit
  32. 25 Apr, 2016 1 commit
  33. 11 Jan, 2016 1 commit
  34. 20 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Initial support for Array constructor specialization. · aeb41de0
      bmeurer authored
      Introduce a JSCreateArray operator that represents the Array
      constructor, and lower call and construct calls to the Array
      constructor to JSCreateArray. Currently we don't yet replace
      that with an inline allocation, but always use the specialized
      stubs for the Array constructor.
      
      This saves a lot of unnecessary deopts and elements transitions
      because now we can actually consume the allocation site feedback
      for the transitions.
      
      R=mstarzinger@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1466643002
      
      Cr-Commit-Position: refs/heads/master@{#32145}
      aeb41de0