1. 04 Aug, 2021 1 commit
  2. 05 May, 2021 1 commit
    • Nico Hartmann's avatar
      [TurboFan] Add %VerifyType intrinsic · f486a343
      Nico Hartmann authored
      This CL adds a new %VerifyType compiler intrinsic that can be used
      by tests and fuzzers to generate a runtime type check of the given
      input value. Internally, %VerifyType is lowered to %AssertType
      which is why checks are currently limited to range types.
      
      tests to be const-correct.
      
      Drive-by: Add a few consts to NodeProperties accessors to allow
      Bug: v8:11724
      Change-Id: I06842062d0e8278a5ba011d5a09947fe05b6e85e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859959
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74377}
      f486a343
  3. 23 Mar, 2021 1 commit
  4. 26 Jan, 2021 1 commit
    • Paolo Severini's avatar
      [test][turbofan] Add %ObserveNode intrinsic for node-specific tests · 4e9f6513
      Paolo Severini authored
      (Initially copied from nicohartmann@ CL
      https://chromium-review.googlesource.com/c/v8/v8/+/2135631)
      
      This CL adds a new intrinsic %ObserveNode(expr) which has noop semantics
      but triggers the new NodeObserver set on the OptimizedCompilationInfo
      when the node generated for expr is created or changed in any phase
      (until EffectControlLinearization).
      
      This provides the infrastructure to write reasonable unit tests that
      check for the construction of or lowering to specific nodes (e.g.
      depending on feedback).
      
      When %ObserveNode(expr) is used an object of class ObserveNodeManager is
      registered to every Reducer/GraphReducer and is notified by the Reducer
      with all node changes. The same logic is added to classes
      SimplifiedLowering/RepresentationSelector, which do not inherit from
      class Reducer.
      
      Observed Node modifications currently are:
       * The Node Operator
       * The Node type
       * Node replacements
      
      A first use case (cctest/test-sloppy-equality.cc) is included in this CL.
      
      Change-Id: Idc5a5e38af8b1d9a2ec5021bf821c4e4e1406220
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555219
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72331}
      4e9f6513
  5. 10 Nov, 2020 1 commit
  6. 09 Nov, 2020 2 commits
  7. 05 Nov, 2020 2 commits
  8. 28 Oct, 2020 1 commit
  9. 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
  10. 10 Dec, 2019 1 commit
  11. 01 Jul, 2019 1 commit
  12. 24 May, 2019 1 commit
  13. 03 May, 2019 1 commit
  14. 02 May, 2019 2 commits
  15. 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
  16. 08 Feb, 2019 1 commit
  17. 12 Oct, 2018 1 commit
  18. 15 Jun, 2018 1 commit
  19. 28 Apr, 2018 1 commit
  20. 23 Feb, 2018 3 commits
  21. 04 Jan, 2018 1 commit
  22. 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
  23. 27 Oct, 2017 1 commit
  24. 07 Sep, 2017 1 commit
  25. 31 Jul, 2017 1 commit
  26. 28 Jul, 2017 4 commits
  27. 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
  28. 10 May, 2017 1 commit
  29. 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
  30. 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
  31. 02 Mar, 2017 1 commit
  32. 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