1. 07 Nov, 2019 1 commit
  2. 26 Aug, 2019 1 commit
  3. 23 Aug, 2019 2 commits
  4. 16 Aug, 2019 2 commits
    • Georg Schmid's avatar
      [turbofan] Track field owner maps during load elimination · f85826ea
      Georg Schmid authored
      This CL adds additional information in PropertyAccessInfos and FieldAccesses about the map that introduced the accessed field. We use this information to prevent load elimination from incorrectly optimizing certain accesses marked const.
      
      Prior to this CL, load elimination simply stored information about eliminatable field accesses based on objects (identified by nodes in the graph) and offsets (i.e., statically known ones). In the presence of const stores and loads this is insufficient, since a single object (in the above sense) may contain distinct *const* properties at the same offset throughout its lifetime. As an example, consider the following piece of code:
      
          let obj = {};
          obj.a = 0;
          obj[1024] = 1;  // An offset of >=1024 forces an elements-kind transition
          delete obj.a;
          obj.b = 2;
          assertEquals(obj.b, 2);
      
      In this scenario, *both* the first ('obj.a = 0') and the second ('obj.b = 2') store to a field will be marked const by the runtime. The reason that storing to 'a' above ends up being marked const, is that 'a' before and after the elements-kind transition is encoded in separate transition trees. Removing 'a' ('delete obj.a') only invalidates const-ness in the dictionary-elements transition tree; not the holey-elements one used at the time of 'obj.a = 0'.
      
      The above situation on its own violates an invariant in load elimination. Namely, we assume that for the same object and offset, we will never encounter two const stores. One can extend the above snippet to coax load-elimination into producing incorrect results. For instance, by "hiding" 'obj.b = 2' in an unoptimized function call, the consecutive load from 'b' will incorrectly produce 0, violating the assert.
      
      R=neis@chromium.org, tebbi@chromium.org
      
      Bug: chromium:980183, chromium:983764
      Change-Id: I576a9c7efd416fa9db6daff1f42d483e4bd369b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751346
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63226}
      f85826ea
    • Santiago Aboy Solanes's avatar
      [ptr-compr][turbofan] Specialize accesses known to be pointers. · 1b7f99a0
      Santiago Aboy Solanes authored
      There are some accesses that we know that are pointers, and we can
      specialize them to have Pointer as their Machine Type and Write Barrier.
      
      Drive-by fix: ForJSGeneratorObjectParametersAndRegisters can be changed
      to use Pointer.
      
      Bug: v8:7703
      Change-Id: I88e371746fc5f08c84795c95b1885264ef6c067c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741658
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63223}
      1b7f99a0
  5. 01 Aug, 2019 1 commit
  6. 21 Jun, 2019 1 commit
  7. 28 May, 2019 1 commit
  8. 22 May, 2019 2 commits
  9. 20 May, 2019 1 commit
  10. 15 May, 2019 3 commits
  11. 10 May, 2019 1 commit
  12. 07 May, 2019 1 commit
  13. 27 Apr, 2019 1 commit
  14. 18 Apr, 2019 1 commit
  15. 12 Apr, 2019 1 commit
  16. 26 Mar, 2019 1 commit
  17. 25 Mar, 2019 1 commit
  18. 06 Mar, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Don't access heap in ReduceElementAccess · 4d39e342
      Georg Neis authored
      This CL builds on top of feedback preprocessing. It brokerizes
      all parts of element access reduction and disallows heap access there
      (except for debug tracing).
      
      To make this work without breaking tests (when concurrent inlining is
      enabled):
      - We don't inline functions that weren't serialized for compilation.
      - We don't optimize for constant typed-array receivers when the typed
        array wasn't serialized.
      
      This means that from now on --concurrent-inlining (and thus --future)
      may result in less optimization than the default configuration.
      
      Bug: v8:7790
      Change-Id: I22685258b7d841fc9183bf99775d3f09cd272927
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495556
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60061}
      4d39e342
  19. 06 Feb, 2019 1 commit
  20. 07 Jan, 2019 1 commit
  21. 17 Dec, 2018 1 commit
  22. 15 Oct, 2018 1 commit
  23. 05 Oct, 2018 1 commit
  24. 21 Sep, 2018 1 commit
  25. 10 Sep, 2018 1 commit
  26. 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
  27. 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
  28. 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
  29. 23 Aug, 2018 1 commit
  30. 17 Jul, 2018 2 commits
  31. 06 Jul, 2018 2 commits
    • Georg Neis's avatar
      Move CompilationDependencies into compiler. · cf87e94c
      Georg Neis authored
      - Move the CompilationDependencies member of OptimizedCompilationInfo
        to Turbofan's PipelineData (and thus into the compiler namespace).
      - Move compilation-dependencies.{cc,h} to the compiler directory.
      
      Bug: v8:7902
      Change-Id: I5471d0923daf83abe975357325db5bc5ad0a8571
      Reviewed-on: https://chromium-review.googlesource.com/1127793
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54295}
      cf87e94c
    • Georg Neis's avatar
      Reland^2 "[turbofan] Rewrite CompilationDependencies" · a1cb1eb9
      Georg Neis authored
      This is a reland of 4b9b9b68, which
      accidentally disabled optimization after dependency changes (instead
      of retrying).
      
      TBR=jarin@chromium.org
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Reland "[turbofan] Rewrite CompilationDependencies"
      >
      > This is a reland of 52a10e50, after
      > eliminating an invalid assumption about maps.
      >
      > TBR=jarin@chromium.org
      > TBR=mstarzinger@chromium.org
      >
      > Original change's description:
      > > [turbofan] Rewrite CompilationDependencies
      > >
      > > Instead of installing code dependencies during graph reduction,
      > > install them after code generation.
      > >
      > > Bug: v8:7902, v8:7790
      > > Change-Id: I8a3798254abb5b9ec7c295a1592aeb6b51f24c7a
      > > Reviewed-on: https://chromium-review.googlesource.com/1119913
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#54170}
      >
      > Bug: v8:7902, v8:7790
      > Change-Id: I9cbaf98980379b9b17464af5952ec0c47e1cdc6f
      > Reviewed-on: https://chromium-review.googlesource.com/1126999
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54254}
      
      Bug: v8:7902, v8:7790
      Change-Id: I2b7a7d186e03990350e375470569177e3309683c
      Reviewed-on: https://chromium-review.googlesource.com/1127579
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54280}
      a1cb1eb9
  32. 05 Jul, 2018 2 commits
    • Georg Neis's avatar
      Revert "Reland "[turbofan] Rewrite CompilationDependencies"" · 9d8d074d
      Georg Neis authored
      This reverts commit 4b9b9b68.
      
      Reason for revert: Regresses Octane.
      
      Original change's description:
      > Reland "[turbofan] Rewrite CompilationDependencies"
      > 
      > This is a reland of 52a10e50, after
      > eliminating an invalid assumption about maps.
      > 
      > TBR=jarin@chromium.org
      > TBR=mstarzinger@chromium.org
      > 
      > Original change's description:
      > > [turbofan] Rewrite CompilationDependencies
      > >
      > > Instead of installing code dependencies during graph reduction,
      > > install them after code generation.
      > >
      > > Bug: v8:7902, v8:7790
      > > Change-Id: I8a3798254abb5b9ec7c295a1592aeb6b51f24c7a
      > > Reviewed-on: https://chromium-review.googlesource.com/1119913
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#54170}
      > 
      > Bug: v8:7902, v8:7790
      > Change-Id: I9cbaf98980379b9b17464af5952ec0c47e1cdc6f
      > Reviewed-on: https://chromium-review.googlesource.com/1126999
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54254}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,neis@chromium.org
      
      Change-Id: Iece193046c48ee96ab7952d2b3bd7ad05f39b190
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7902, v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/1127119Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54260}
      9d8d074d
    • Georg Neis's avatar
      Reland "[turbofan] Rewrite CompilationDependencies" · 4b9b9b68
      Georg Neis authored
      This is a reland of 52a10e50, after
      eliminating an invalid assumption about maps.
      
      TBR=jarin@chromium.org
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > [turbofan] Rewrite CompilationDependencies
      >
      > Instead of installing code dependencies during graph reduction,
      > install them after code generation.
      >
      > Bug: v8:7902, v8:7790
      > Change-Id: I8a3798254abb5b9ec7c295a1592aeb6b51f24c7a
      > Reviewed-on: https://chromium-review.googlesource.com/1119913
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54170}
      
      Bug: v8:7902, v8:7790
      Change-Id: I9cbaf98980379b9b17464af5952ec0c47e1cdc6f
      Reviewed-on: https://chromium-review.googlesource.com/1126999Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54254}
      4b9b9b68