1. 30 Nov, 2018 1 commit
    • Peter Marshall's avatar
      Revert "[runtime] Reduce spread/apply call max arguments" · ff0cf00c
      Peter Marshall authored
      This reverts commit 4e3a17d0.
      
      Reason for revert: Web compact issues, see crbug.com/910252
      
      Original change's description:
      > [runtime] Reduce spread/apply call max arguments
      > 
      > Bug: chromium:906043
      > Change-Id: I308b29af0644c318d73926b27e65a94913c760c7
      > Reviewed-on: https://chromium-review.googlesource.com/c/1346115
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57731}
      
      TBR=jarin@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:906043
      Change-Id: I240c1b55c10fd3e108e3c49f93ce1d9ca9c61780
      Reviewed-on: https://chromium-review.googlesource.com/c/1356502Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57956}
      ff0cf00c
  2. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  3. 22 Nov, 2018 1 commit
  4. 22 Oct, 2018 1 commit
  5. 15 Oct, 2018 1 commit
  6. 28 Sep, 2018 1 commit
    • Daniel Clifford's avatar
      Clean up common argument objects that share length property · 64e8a948
      Daniel Clifford authored
      This CL adds a bit more rigor to the handling of length properties
      in JSObject-derived classes that explicitly contain that property
      inline.
      
      This involves:
      - Introducing a new superclass of JSArgumentsObject called
        JSArgumentsObjectWithLength that is shared with other object
        instances that also have a fixed length property.
      - Adding JSArgumentsObjectWithLength to the type hierarchy in Torque,
        including adding fast-cases for leading the length property for all
        classes deriving from JSObjectWithLength.
      - Adding more rigor to Context and NativeContext handling in base.tq.
        This is useful for the map checks required to verify objects are
        argument object types derived from JSArgumentsObjectWithLength.
      
      Change-Id: I2f0a20601ffcb90b3767cbaeb766e9998d3462ec
      Reviewed-on: https://chromium-review.googlesource.com/1248661
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56289}
      64e8a948
  7. 21 Sep, 2018 1 commit
  8. 20 Sep, 2018 3 commits
  9. 19 Sep, 2018 1 commit
  10. 14 Sep, 2018 1 commit
    • Jakob Gruber's avatar
      Revert "[builtins] Add FastCallFunction builtin that elides some checks" · 74320a1b
      Jakob Gruber authored
      This reverts commit 99e13e58.
      
      Reason for revert: Reverting in favor of a general mechanism for this in Torque.
      
      Original change's description:
      > [builtins] Add FastCallFunction builtin that elides some checks
      > 
      > This CL adds a new "Call" stub that can be used by builtins that will
      > call the same JS call-back function often (e.g. compare function in
      > Array.p.sort). The checks have to be done upfront once, but can then
      > be omitted.
      > 
      > R=​jgruber@chromium.org
      > 
      > Bug: v8:7861
      > Change-Id: Id6e4ca27c3d488a7b1f708cbcb4cbe6cc382513e
      > Reviewed-on: https://chromium-review.googlesource.com/1208574
      > Commit-Queue: Simon Zünd <szuend@google.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55769}
      
      TBR=cbruni@chromium.org,jgruber@chromium.org,szuend@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7861
      Change-Id: I47260993ef2a16bd5348bb0b46da4d34d33ea10b
      Reviewed-on: https://chromium-review.googlesource.com/1226871
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55897}
      74320a1b
  11. 11 Sep, 2018 1 commit
  12. 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
  13. 28 Aug, 2018 1 commit
  14. 17 Aug, 2018 1 commit
  15. 13 Aug, 2018 1 commit
  16. 09 Aug, 2018 1 commit
  17. 25 Jun, 2018 2 commits
  18. 19 Jun, 2018 1 commit
  19. 18 Jun, 2018 1 commit
  20. 06 Jun, 2018 1 commit
  21. 01 Jun, 2018 1 commit
  22. 30 May, 2018 1 commit
  23. 13 Mar, 2018 1 commit
  24. 12 Mar, 2018 1 commit
  25. 02 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Extend the array iterator protector. · 1525374f
      Benedikt Meurer authored
      Previously the array iterator protector only guarded the lookup of the
      @@iterator symbol on the initial Array.prototype, and we had to use an
      additional map check on the %ArrayIteratorPrototype% to ensure that no
      one messed with the next() method.  This CL extends the array iterator
      protector to also guard the lookup of %ArrayIteratorPrototype%.next.
      
      This simplifies the code quite a bit and makes it more robust for cases
      where someone has to install additional methods on the iterator
      prototype, i.e. a custom async iterator.
      
      Bug: v8:7510, v8:7514
      Change-Id: Ie6080bb837a91a2b60b224597121470614210660
      Reviewed-on: https://chromium-review.googlesource.com/945728Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51684}
      1525374f
  26. 23 Feb, 2018 1 commit
  27. 18 Jan, 2018 1 commit
  28. 20 Nov, 2017 1 commit
  29. 20 Oct, 2017 1 commit
  30. 13 Oct, 2017 1 commit
  31. 02 Oct, 2017 1 commit
  32. 13 Sep, 2017 1 commit
  33. 07 Aug, 2017 1 commit
  34. 13 Jul, 2017 1 commit
  35. 10 Jul, 2017 1 commit
  36. 30 Jun, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
      with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
      vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
      
      This patch renames the FAST elements kinds as follows:
      
      - e.g. FAST_ELEMENTS => PACKED_ELEMENTS
      - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
      
      The following exceptions are left intact, for lack of a better name:
      
      - FAST_SLOPPY_ARGUMENTS_ELEMENTS
      - SLOW_SLOPPY_ARGUMENTS_ELEMENTS
      - FAST_STRING_WRAPPER_ELEMENTS
      - SLOW_STRING_WRAPPER_ELEMENTS
      
      This makes it easier to reason about elements kinds, and less confusing to
      explain how they’re used.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
      Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
  37. 21 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce new JSConstructWithArrayLike operator. · 21701297
      bmeurer authored
      Add a new JSConstructWithArrayLike operator that is backed by the
      ConstructWithArrayLike builtin (similar to what was done before
      for the JSCallWithArrayLike operator), and use that operator to
      optimize Reflect.construct inlining in TurboFan. This is handled
      uniformly with JSConstructWithSpread in the JSCallReducer.
      
      Also add missing test coverage for Reflect.construct in optimized
      code, especially for some interesting corner cases.
      
      R=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2949813002
      Cr-Commit-Position: refs/heads/master@{#46087}
      21701297