1. 05 Sep, 2018 1 commit
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored
      This is a reland of 1c48d52b.
      
      It turned out that IterableToList doesn't always behave according to
      the ES operation with the same name. Specifically, it allows holey arrays
      to take its fast path, which produces an output array with holes where
      actually "undefined" elements should appear.
      
      This CL changes the version of IterableToList that is used for spreads
      (IterableToListWithSymbolLookup) such that holey arrays take the slow path.
      It also includes tests for such situations.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      >
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      >
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      >
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      >
      > Bug: v8:7980
      >
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      Bug: v8:7980
      Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1201882
      Commit-Queue: Hai Dang <dhai@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  2. 03 Sep, 2018 1 commit
  3. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored
      This reverts commit 1c48d52b.
      
      Reason for revert: Clusterfuzz found something.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      > 
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      > 
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      > 
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      > 
      > Bug: v8:7980
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
      
      Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7980
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  4. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored
      This CL improves the performance of creating [...a, b] or [...a].
      If the array literal has a leading spread, this CL emits the bytecode
      [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      is implemented by [IterableToListDefault] builtin to create the initial
      array for the leading spread. IterableToListDefault has a fast path to
      clone efficiently if the spread is an actual array.
      
      The bytecode generated is now shorter. Bytecode generation is refactored
      into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      from this optimization also.
      For now, turbofan also lowers the bytecode to the builtin.
      
      The idiomatic use of [...a] to clone the array a now performs better
      than a simple for-loop, but still does not match the performance of slice.
      
      Bug: v8:7980
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Commit-Queue: Hai Dang <dhai@google.com>
      Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  5. 29 Aug, 2018 1 commit
    • Maya Lekova's avatar
      [turbofan] Introduce a CheckStringAdd node instead of cons string lowering · 6a7872b7
      Maya Lekova authored
      The new node is introduced for literal string addition and calling
      String.prototype.concat in the typed lowering phase. It later might get optimized
      away during redundancy elimination, keeping the performance of already existing
      benchmarks with string addition. In case the operation is about to throw
      (due to too long string being constructed) we just deoptimize, reusing
      the interpreter logic for creating the error.
      
      Modify relevant mjsunit and unit tests for string concatenation.
      
      Bug: v8:7902
      Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3
      Reviewed-on: https://chromium-review.googlesource.com/1193342
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55482}
      6a7872b7
  6. 21 Aug, 2018 1 commit
  7. 13 Aug, 2018 1 commit
  8. 31 Jul, 2018 1 commit
  9. 23 Jul, 2018 2 commits
  10. 20 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58
  11. 19 Jul, 2018 2 commits
    • 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
    • Leszek Swirski's avatar
      [sfi] Remove SFI function identifier field · c941f11a
      Leszek Swirski authored
      Remove the function identifier field from SharedFunctionInfo. This field
      would store one of a) the function's inferred name, b) the "builtin
      function id", or c) debug info. We remove these in turn:
      
      a) The function's inferred name is available on the ScopeInfo, so like
         the start/end position we read it off either the ScopeInfo (for
         compiled functions) or the UncompiledData (for uncompiled functions).
      
         As a side-effect, now both UncompiledData and its subclass,
         UncompiledDataWithPreparsedScope, contain a pointer field. To keep
         BodyDescriptors manageable, we introduce a SubclassBodyDescriptor
         which effectively appends two BodyDescriptors together.
      
      b) The builtin function id is < 255, so we can steal a byte from
         expected no. of properies (also <255) and store these together.
         Eventually we want to get rid of this field and use the builtin ID,
         but this is pending JS builtin removal.
      
         As a side-effect, BuiltinFunctionId becomes an enum class (for better
         storage size guarantees).
      
      c) The debug info can hang off anything (since it stores the field it
         replaces), so we can attach it to the script field instead.
      
      This saves a word on compiled function (uncompiled functions
      unfortunately still have to store it in UncompiledData).
      
      Bug: chromium:818642
      Change-Id: I8b4b3a070f0fe328aafcaeac58842d144d12d996
      Reviewed-on: https://chromium-review.googlesource.com/1138328Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54543}
      c941f11a
  12. 16 Jul, 2018 1 commit
  13. 10 Jul, 2018 1 commit
  14. 09 Jul, 2018 1 commit
    • Théotime Grohens's avatar
      [turbofan] Add DataView setters in TurboFan · c4323e08
      Théotime Grohens authored
      This CL completes the implementation of DataView prototype methods
      in TurboFan, by implementing the Uint8, Int8, Uint16, Int16,
      Uint32, Int32, Float32 and Float64 setters.
      
      DataView performance is now ahead of the equivalent TypedArray wrapper,
      and is now expected to at least match TypedArray performance in
      the general case as well.
      
      This CL also adds a test file in the compiler directory, to make
      sure that the setters actually behave correctly.
      
      Change-Id: I4ad4341c6b9b9d461348b62216f37a73abe321e8
      Reviewed-on: https://chromium-review.googlesource.com/1128867Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Théotime Grohens <theotime@google.com>
      Cr-Commit-Position: refs/heads/master@{#54331}
      c4323e08
  15. 04 Jul, 2018 1 commit
  16. 18 Jun, 2018 1 commit
  17. 14 Jun, 2018 3 commits
  18. 13 Jun, 2018 1 commit
  19. 12 Jun, 2018 1 commit
  20. 11 Jun, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Add inlining for RegExp#test · 394d53d1
      Sigurd Schneider authored
      This CL adds a TFS stub for RegExp#test and moves several checks to
      the JSCallReducer. In particular, the JSCallReducer checks that
       - property {exec} on the regexp is still the original exec
       - property {lastIndex} on the regexp is a non-negative smi
      The stub does not repeat these checks in release mode.
      
      This effectively means that if the regexp is known, we can perform these
      checks at compile time, and get away with a map dependency.
      
      Bug: v8:7779, v8:7200
      
      Change-Id: I0c6d711d4f1d2f6f325a1c02855b0e1b62e014c8
      Reviewed-on: https://chromium-review.googlesource.com/1074654
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53630}
      394d53d1
  21. 07 Jun, 2018 2 commits
  22. 25 May, 2018 1 commit
  23. 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
  24. 03 May, 2018 1 commit
  25. 30 Apr, 2018 2 commits
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
    • Jaroslav Sevcik's avatar
      [turbofan] Remove the hacky Type::operator-> overload · ba616de1
      Jaroslav Sevcik authored
      This removes Type::operator-> which was used to split the change that
      removed undefined misuse of Type* to represent integers.
      
      Bug: v8:3770
      Change-Id: I9a5bce5ccdc75461a7b939b4070cb58fe6040d99
      Reviewed-on: https://chromium-review.googlesource.com/1033736Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52878}
      ba616de1
  26. 28 Apr, 2018 1 commit
  27. 26 Apr, 2018 1 commit
  28. 25 Apr, 2018 1 commit
  29. 24 Apr, 2018 1 commit
  30. 23 Apr, 2018 1 commit
  31. 19 Apr, 2018 1 commit
  32. 04 Apr, 2018 1 commit
  33. 23 Mar, 2018 2 commits