1. 07 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Eliminate redundant Smi checks around array accesses. · bcdede0c
      Benedikt Meurer authored
      As identified in the web-tooling-benchmark, there are specific code
      patterns involving array indexed property accesses and subsequent
      comparisons of those indices that lead to repeated Smi checks in the
      optimized code, which in turn leads to high register pressure and
      generally bad register allocation. An example of this pattern is
      code like this:
      
      ```js
      function f(a, n) {
        const i = a[n];
        if (n >= 1) return i;
      }
      ```
      
      The `a[n]` property access introduces a CheckBounds on `n`, which
      later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`,
      however the `n >= 1` comparison has collected `SignedSmall` feedback
      and so it introduces a `CheckedTaggedToTaggedSigned` operation. This
      second Smi check is redundant and cannot easily be combined with the
      earlier tagged->int32 conversion, since that also deals with heap
      numbers and even truncates -0 to 0.
      
      So we teach the RedundancyElimination to look at the inputs of these
      speculative number comparisons and if there's a leading bounds check
      on either of these inputs, we change the input to the result of the
      bounds check. This avoids the redundant Smi checks later and generally
      allows the SimplifiedLowering to do a significantly better job on the
      number comparisons. We only do this in case of SignedSmall feedback
      and only for inputs that are not already known to be in UnsignedSmall
      range, to avoid doing too many (unnecessary) expensive lookups during
      RedundancyElimination.
      
      All of this is safe despite the fact that CheckBounds truncates -0
      to 0, since the regular number comparisons in JavaScript identify
      0 and -0 (unlike Object.is()). This also adds appropriate tests,
      especially for the interesting cases where -0 is used only after
      the code was optimized.
      
      Bug: v8:6936, v8:7094
      Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07
      Reviewed-on: https://chromium-review.googlesource.com/c/1246181Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56428}
      bcdede0c
  2. 20 Sep, 2018 1 commit
  3. 19 Sep, 2018 1 commit
  4. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored
      Each reducer now has a virtual reducer_name function, returning its name
      (the name of the class containing this reducer). This gets displayed when
      using the --trace_turbo_reduction flag. Also when using this flags more
      messages are displayed.
      
      Actually when a node is replaced in-place (which is called an update
      of the node), other reducers can still update it right after the
      in-place replacement. When a node is really replaced (not in-place),
      then we stop trying to apply reducers to it before we propagate the
      reduction through the relevant nodes.
      
      Before a message got printed only for the last reduction it went
      through. So in case a node was reduced in-place several times
      in a row, only the last update was printed, or none at all if after
      being reduced in-place it got reduced by being replaced by another
      node: only the non-in-place replacement was showed. 
      
      Now each time an in-place reduction is applied to a node, a message
      gets printed.
      
      Bug: 
      Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
      Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34
  5. 24 Nov, 2016 1 commit
  6. 29 Jun, 2016 1 commit
  7. 23 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Initial version of RedundancyElimination. · 5250da68
      bmeurer authored
      The redundancy elimination is currently a graph reducer that tries to
      combine redundant checks in the effect chain. It does this by
      propagating the checks that happened along effect paths, which is pretty
      similar to what the BranchElimination does on the control chain. We run
      this reducer together with the other optimizations right after the
      representation selection.
      
      An upcoming CL will extend the redundancy elimination to also eliminate
      redundant loads (and eventually map checks).
      
      R=jarin@chromium.org
      BUG=v8:5141
      
      Review-Url: https://codereview.chromium.org/2091503003
      Cr-Commit-Position: refs/heads/master@{#37208}
      5250da68