1. 15 Jul, 2019 1 commit
  2. 12 Jul, 2019 1 commit
  3. 02 Jul, 2019 1 commit
  4. 26 Jun, 2019 1 commit
  5. 25 Jun, 2019 2 commits
  6. 23 May, 2019 1 commit
  7. 18 Apr, 2019 2 commits
  8. 29 Mar, 2019 1 commit
  9. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored
      This change significantly improves the performance of string
      concatenation in optimized code for the case where the resulting string
      is represented as a ConsString. On the relevant test cases we go from
      
        serializeNaive: 10762 ms.
        serializeClever: 7813 ms.
        serializeConcat: 10271 ms.
      
      to
      
        serializeNaive: 10278 ms.
        serializeClever: 5533 ms.
        serializeConcat: 10310 ms.
      
      which represents a 30% improvement on the "clever" benchmark, which
      tests specifically the ConsString creation performance.
      
      This was accomplished via a couple of different steps, which are briefly
      outlined here:
      
        1. The empty_string gets its own map, so that we can easily recognize
           and handle it appropriately in the TurboFan type system. This
           allows us to express (and assert) that the inputs to NewConsString
           are non-empty strings, making sure that TurboFan no longer creates
           "crippled ConsStrings" with empty left or right hand sides.
        2. Further split the existing String types in TurboFan to be able to
           distinguish between OneByte and TwoByte strings on the type system
           level. This allows us to avoid having to dynamically lookup the
           resulting ConsString map in case of ConsString creation (i.e. when
           we know that both input strings are OneByte strings or at least
           one of the input strings is TwoByte).
        3. We also introduced more finegrained feedback for the Add bytecode
           in the interpreter, having it collect feedback about ConsStrings,
           specifically ConsOneByteString and ConsTwoByteString. This feedback
           can be used by TurboFan to only inline the relevant code for what
           was seen so far. This allows us to remove the Octane/Splay specific
           magic in JSTypedLowering to detect ConsString creation, and instead
           purely rely on the feedback of what was seen so far (also making it
           possible to change the semantics of NewConsString to be a low-level
           operator, which is only introduced in SimplifiedLowering by looking
           at the input types of StringConcat).
        4. On top of the before mentioned type and interpreter changes we added
           new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
           CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
           checks.
      
      There are several more improvements that are possible based on this, but
      since the change was already quite big, we decided not to put everything
      into the first change, but do some follow up tweaks to the type system,
      and builtin optimizations later.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:8834, v8:8931, v8:8939, v8:8951
      Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  10. 02 Jan, 2019 1 commit
  11. 21 Nov, 2018 1 commit
  12. 19 Nov, 2018 1 commit
    • Georg Neis's avatar
      Revert "[turbofan] Improve NumberMultiply typing rule." · 858fc3f6
      Georg Neis authored
      This reverts commit 585b4eef.
      
      Reason for revert: Speculative, crbug 906567.
      
      Original change's description:
      > [turbofan] Improve NumberMultiply typing rule.
      > 
      > The NumberMultiply typing rule gave up in the presence of NaN inputs,
      > but we can still infer useful ranges here and just union the result
      > of that with the NaN propagation (similar for MinusZero propagation).
      > This way we can still makes sense of these ranges at the uses.
      > 
      > Bug: v8:8015
      > Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
      > Reviewed-on: https://chromium-review.googlesource.com/c/1261143
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56539}
      
      TBR=sigurds@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8015
      Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330
      Reviewed-on: https://chromium-review.googlesource.com/c/1340253Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57602}
      858fc3f6
  13. 15 Oct, 2018 1 commit
  14. 10 Oct, 2018 1 commit
  15. 25 Sep, 2018 1 commit
  16. 07 Sep, 2018 1 commit
  17. 03 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Improve typing of ToNumeric and ToNumber. · b8981122
      Benedikt Meurer authored
      The previous typing rules for ToNumeric and ToNumber didn't match on the
      NonBigIntPrimitive input set, which causes trouble when we morph ToNumeric
      nodes into ToNumber nodes, and generally lead to worse typings in the
      graph, and thus worse code generation. This change improves the existing
      typing rules and turns ToNumber into a chokepoint again.
      
      Bug: chromium:879898, v8:8015
      Change-Id: I4a7ff0e9c420c5dcfdb2b96884e019a5943828a4
      Reviewed-on: https://chromium-review.googlesource.com/1201522Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55595}
      b8981122
  18. 23 Jul, 2018 2 commits
  19. 19 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      Revert "[turbofan] Inline Number constructor in certain cases" · c7a9af61
      Sigurd Schneider authored
      This reverts commit 9eca23e9.
      
      Reason for revert: Clusterfuzz correctness issue
      
      Original change's description:
      > [turbofan] Inline Number constructor in certain cases
      > 
      > This CL adds inlining for the Number constructor if new.target is not
      > present. The lowering is BigInt compatible, i.e. it converts BigInts to
      > numbers.
      > 
      > Bug: v8:7904
      > Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82
      > Reviewed-on: https://chromium-review.googlesource.com/1118557
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54454}
      
      TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7904
      Change-Id: Ie5fa6c1262b8acc33edb672a0124f4458fcded86
      Reviewed-on: https://chromium-review.googlesource.com/1142777Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54544}
      c7a9af61
  20. 16 Jul, 2018 1 commit
  21. 07 Jun, 2018 1 commit
  22. 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
  23. 28 Apr, 2018 1 commit
  24. 17 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce NumberToString operator. · 02dbef14
      Benedikt Meurer authored
      This adds a new simplified operator NumberToString, which just lowers to
      a call to the NumberToString builtin, and hooks that up to the typed
      lowering (addressing a long-standing TODO).
      
      Drive-by-fix: Also remove the %NumberToString runtime entry, and just
      always use the %NumberToStringSkipCache entry from CSA, since we only
      go there if the cache lookup already failed.
      
      Bug: v8:5267, v8:7109
      Change-Id: I5ca698c98679653813088a404f1fd38903a73c0e
      Reviewed-on: https://chromium-review.googlesource.com/779099
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50636}
      02dbef14
  25. 21 Nov, 2017 1 commit
  26. 02 Nov, 2017 1 commit
  27. 27 Oct, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Introduce SameValue operator. · c78a98bb
      Benedikt Meurer authored
      We now represent the SameValue operation explicitly in TurboFan and the
      operation can thus participate in all kinds of optimizations. Especially
      we get rid of the JSCall node in the general case, which blocks several
      optimizations across the call. The general, baseline performance is now
      always on par with StrictEqual.
      
      Once the StrictEqual operator is also a simplified operator, we should
      start unifying the type based optimizations in SimplifiedLowering.
      
      In the micro-benchmark we go from
      
        testStrictEqual: 1422 ms.
        testObjectIs: 1520 ms.
        testManualSameValue: 1759 ms.
      
      to
      
        testStrictEqual: 1426 ms.
        testObjectIs: 1357 ms.
        testManualSameValue: 1766 ms.
      
      which gives the expected result.
      
      Bug: v8:7007
      Change-Id: I0de3ff6ff6209ab4c3edb69de6a16e387295a9c8
      Reviewed-on: https://chromium-review.googlesource.com/741228Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48994}
      c78a98bb
    • Jaroslav Sevcik's avatar
      [turbofan] Make ConvertReceiver a simplified operator. · 70b1f15e
      Jaroslav Sevcik authored
      This enables proper wiring into ithe control flow chain.
      
      Bug: v8:7002,chromium:777574
      Change-Id: Idba59944ff6ab3c10c204bb74ace61d812e6297c
      Reviewed-on: https://chromium-review.googlesource.com/738183Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48990}
      70b1f15e
  28. 29 Aug, 2017 1 commit
  29. 12 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Properly represent the float64 hole. · 8c0c5e81
      bmeurer authored
      The hole NaN should also have proper Type::Hole, and not silently hide
      in the Type::Number. This way we can remove all the special casing for
      the hole NaN, and we also finally get the CheckNumber right.
      
      This also allows us to remove some ducktape from the Deoptimizer, as for
      escape analyzed FixedDoubleArrays we always pass the hole value now to
      represent the actual holes.
      
      Also-By: jarin@chromium.org
      BUG=chromium:684208,chromium:709753,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2814013003
      Cr-Commit-Position: refs/heads/master@{#44603}
      8c0c5e81
  30. 07 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce a SpeculativeToNumber operator. · e6ca0146
      bmeurer authored
      Add a dedicated operator for ToNumber(x) with feedback instead of
      translating to SpeculativeNumberMultiply(x,1), which allows us to
      treat the case where x is already a Number specially, ignoring the
      feedback on the operator. This recovers most of the regression in
      the crypto benchmark.
      
      BUG=chromium:709398,v8:6214,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2802113003
      Cr-Commit-Position: refs/heads/master@{#44484}
      e6ca0146
  31. 17 Mar, 2017 1 commit
  32. 05 Sep, 2016 1 commit
  33. 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
  34. 08 Aug, 2016 2 commits
  35. 05 Aug, 2016 1 commit