1. 26 Feb, 2019 1 commit
  2. 24 Feb, 2019 1 commit
  3. 20 Feb, 2019 1 commit
    • peterwmwong's avatar
      Reland "[builtins]: Optimize CreateTypedArray to use element size log 2 for calculations." · 02b9847f
      peterwmwong authored
      This is a reland of c9ef0405
      
      Original change's description:
      > [builtins]: Optimize CreateTypedArray to use element size log 2 for calculations.
      >
      > TypedArrayElementsInfo now represents an element's size as a log 2 and typed as
      > uintptr.  This simplifies and speeds up (avoids possible HeapNumber allocations) a
      > number of calculations:
      >
      >   - Number of Elements (length) -> Byte Length - is now a WordShl
      >   - Byte Length -> Number of Elements (length) - is now a WordShr
      >   - Testing alignment (byte offset or length)  - is now a WordAnd
      >
      > These element/byte length related calculations are encapsulated in
      > TypedArrayElementsInfo as struct methods.
      >
      > This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release:
      >   - Before: 9,088
      >   - After:  6,896
      >
      > This improves the performance of the following microbencmarks
      >   - TypedArrays-ConstructWithBuffer: ~87%
      >   - TypedArrays-SubarrayNoSpecies:   ~28%
      >
      > Bug: v8:7161
      > Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44
      > Reviewed-on: https://chromium-review.googlesource.com/c/1456299
      > Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59531}
      
      Bug: v8:7161, chromium:932034
      Change-Id: I5c3dc34c549234417f95b404e7d49b2fd496fa69
      Reviewed-on: https://chromium-review.googlesource.com/c/1476306
      Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59728}
      02b9847f
  4. 18 Feb, 2019 1 commit
    • Jakob Gruber's avatar
      Revert "[builtins]: Optimize CreateTypedArray to use element size log 2 for calculations." · ced2e4ee
      Jakob Gruber authored
      This reverts commit c9ef0405.
      
      Reason for revert: https://crbug.com/932034
      
      Original change's description:
      > [builtins]: Optimize CreateTypedArray to use element size log 2 for calculations.
      >
      > TypedArrayElementsInfo now represents an element's size as a log 2 and typed as
      > uintptr.  This simplifies and speeds up (avoids possible HeapNumber allocations) a
      > number of calculations:
      >
      >   - Number of Elements (length) -> Byte Length - is now a WordShl
      >   - Byte Length -> Number of Elements (length) - is now a WordShr
      >   - Testing alignment (byte offset or length)  - is now a WordAnd
      >
      > These element/byte length related calculations are encapsulated in
      > TypedArrayElementsInfo as struct methods.
      >
      > This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release:
      >   - Before: 9,088
      >   - After:  6,896
      >
      > This improves the performance of the following microbencmarks
      >   - TypedArrays-ConstructWithBuffer: ~87%
      >   - TypedArrays-SubarrayNoSpecies:   ~28%
      >
      > Bug: v8:7161
      > Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44
      > Reviewed-on: https://chromium-review.googlesource.com/c/1456299
      > Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59531}
      
      TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,petermarshall@chromium.org,szuend@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7161, chromium:932034
      Change-Id: I3da95447ce34f84d01629d2791868f3adcdfb387
      Reviewed-on: https://chromium-review.googlesource.com/c/1475764
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59645}
      ced2e4ee
  5. 12 Feb, 2019 1 commit
    • peterwmwong's avatar
      [builtins]: Optimize CreateTypedArray to use element size log 2 for calculations. · c9ef0405
      peterwmwong authored
      TypedArrayElementsInfo now represents an element's size as a log 2 and typed as
      uintptr.  This simplifies and speeds up (avoids possible HeapNumber allocations) a
      number of calculations:
      
        - Number of Elements (length) -> Byte Length - is now a WordShl
        - Byte Length -> Number of Elements (length) - is now a WordShr
        - Testing alignment (byte offset or length)  - is now a WordAnd
      
      These element/byte length related calculations are encapsulated in
      TypedArrayElementsInfo as struct methods.
      
      This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release:
        - Before: 9,088
        - After:  6,896
      
      This improves the performance of the following microbencmarks
        - TypedArrays-ConstructWithBuffer: ~87%
        - TypedArrays-SubarrayNoSpecies:   ~28%
      
      Bug: v8:7161
      Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44
      Reviewed-on: https://chromium-review.googlesource.com/c/1456299
      Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59531}
      c9ef0405
  6. 04 Feb, 2019 1 commit
  7. 28 Jan, 2019 1 commit
    • peterwmwong's avatar
      [builtins] Port TypedArray TypedArrayInitializeWithBuffer to Torque · 8e13ddc6
      peterwmwong authored
      Two small changes were done as part of the port:
      - Changes TypedArrayInitializeWithBuffer from a TFS builtin to a macro.
        It was only called from ConstructByArrayBuffer and this removes the
        overhead of the TFS call.
      - Introduces a GetTypedArrayElementsInfo that retrieves both the element
        size and map. Instead of generating the elements kind switch code (
        DispatchTypedArrayByElementsKind) twice, just generate once at the
        beginning of CreateTypedArray.
      
      This reduces overall builtins size by 364 bytes (Mac x64.release)
        - Before
          1364 - TypedArrayInitializeWithBuffer
          6468 - CreateTypedArray
        - After
          7468 - CreateTypedArray
      
      This also improves performance of TypedArray JSPerf benchmarks
      (SubarrayNoSpecies, ConstructByArrayBuffer) by 5-8%.
      
      Bug: v8:7161
      Change-Id: I68eed2ea4db103f44ad9751229c29fba9bc9d24d
      Reviewed-on: https://chromium-review.googlesource.com/c/1437822
      Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59135}
      8e13ddc6
  8. 26 Jan, 2019 1 commit
  9. 24 Jan, 2019 1 commit
  10. 23 Jan, 2019 1 commit
  11. 22 Jan, 2019 1 commit
  12. 21 Jan, 2019 1 commit
  13. 19 Dec, 2018 2 commits
  14. 11 Dec, 2018 1 commit
  15. 22 Nov, 2018 1 commit
  16. 21 Nov, 2018 1 commit
  17. 13 Nov, 2018 1 commit
    • peterwmwong's avatar
      [builtins] Fast path TA.p.subarray creating TypedArray when default constructor is used · 7c35c03b
      peterwmwong authored
      Previously, the following call sequence was always made when creating resulting
      subsetted TypedArray:
      1) TFJ TypedArrayPrototypeSubArray
      2) TFS TypedArrayConstructor
      3) TFS CreateTypedArray
      
      This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is
      safe to use (IsPrototypeTypedArrayPrototype and
      !IsTypedArraySpeciesProtectorCellInvalid).
      
      Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement...
      
      BEFORE
      TypedArrays-SubarrayNoSpecies(Score): 1033530
      TypedArrays-SubarrayNoSpecies(Score): 1018490
      TypedArrays-SubarrayNoSpecies(Score): 1037030
      
      AFTER
      TypedArrays-SubarrayNoSpecies(Score): 1439030
      TypedArrays-SubarrayNoSpecies(Score): 1417540
      TypedArrays-SubarrayNoSpecies(Score): 1405980
      
      Bug: v8:7161
      Change-Id: I356dace36570aa161ffe208a57a80e46714121a2
      Reviewed-on: https://chromium-review.googlesource.com/c/1331154
      Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57458}
      7c35c03b
  18. 30 Oct, 2018 1 commit
  19. 26 Oct, 2018 1 commit
    • Peter Marshall's avatar
      [typedarray] Use fast path for Float32Array.from(float_64_array) and similar · c7c0e110
      Peter Marshall authored
      Currently, because the source float_64_array has an iterator, it hits
      the code in the "check_iterator" section of TypedArrayFrom which calls
      IterableToList. This builds a temporary PACKED_ELEMENTS array (and boxes
      all of the numeric values as HeapNumbers), then uses this as the source
      array.
      
      This patch checks if the source array is a TypedArray, and if the iterator
      is the built-in one (where we know the iterator's behaviour). If both are
      true then it bypasses the creation of this temporary array and uses the
      original TypedArray as the source.
      
      This allows it to take advantage of the existing fast code for copying one
      typed array to another.
      
      R=hablich@chromium.org, petermarshall@chromium.org
      
      Bug: chromium:884671
      Change-Id: I19a944c9d6d5d07699c7dc3ad7196fc871200b62
      Reviewed-on: https://chromium-review.googlesource.com/c/1297312Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57022}
      c7c0e110
  20. 24 Oct, 2018 1 commit
  21. 26 Sep, 2018 1 commit
  22. 21 Sep, 2018 1 commit
  23. 20 Sep, 2018 1 commit
  24. 19 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Clear JSTypedArray raw fields in the constructor. · 984048e8
      Benedikt Meurer authored
      The JSTypedArray instance is created early on in the TypedArray
      constructors, using EmitFastNewObject, which puts Undefined into
      all slots. But the code might still produce an exception afterwards
      leaving the JSTypedArray in a weird state. It's not a security issue
      since the object doesn't escape, but it confuses the heap verifier.
      
      Bug: chromium:885404, v8:4153, v8:7881, v8:8171
      Change-Id: I5fb8131fcae69edf4a92602ed477dca305c3d6c7
      Reviewed-on: https://chromium-review.googlesource.com/1233257
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56019}
      984048e8
  25. 18 Sep, 2018 1 commit
  26. 17 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Cleanup JSArrayBuffer and TurboFan's handling of neutering. · beebb236
      Benedikt Meurer authored
      Cleanup the JSArrayBuffer bit fields to use the proper object macros
      that are now otherwise used consistently across the code base. Also
      change TurboFan to consistently bailout when it sees an array buffer
      that was previously neutered, so that the generic path / builtins are
      again the chokepoints for the spec violations (the fact that we don't
      always raise exceptions when we see a neutered array buffer), except
      for the ArrayBufferView accessor inlining in the JSCallReducer, where
      we still turn the values into zero (because we don't have access to
      a CALL_IC speculation guard in the common case).
      
      This also removes the ArrayBufferWasNeutered simplified operator, and
      does regular LoadField + Number bitwise operations instead, which is
      good enough and allows us to get rid of a lot of unnecessary complexity.
      
      Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
      Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
      Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55958}
      beebb236
  27. 13 Sep, 2018 2 commits
  28. 11 Sep, 2018 1 commit
  29. 10 Sep, 2018 1 commit
  30. 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
  31. 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
  32. 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
  33. 21 Aug, 2018 2 commits
  34. 13 Aug, 2018 1 commit
  35. 31 Jul, 2018 2 commits
  36. 24 Jul, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Prepare to support 4GiB memories · dab10765
      Ben L. Titzer authored
      This is a preparatory CL that refactors the WASM memory allocation path,
      the WasmGraphBuilder, and several points of contact for ArrayBuffers to
      allow them to eventually be up to 4GiB.
      
      1.) Refactor definition of constants to prepare for memories of size 2^32
      2.) Refactor WasmInstanceObject fields memory_size and memory_mask to
          be stored as uintptr_t
      3.) Refactor WasmGraphBuilder to use 64-bit comparisons for bounds checks
      4.) Refactor JSArrayBuffer accessor methods to use size_t properly.
      5.) Add empirical maximum memory and array buffer size tests
      
      R=mstarzinger@chromium.org
      BUG=v8:7881
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I78a49069cfa89757cc93f0a30b1c1a99c4b2edba
      Reviewed-on: https://chromium-review.googlesource.com/1112003
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54646}
      dab10765