1. 04 Nov, 2019 1 commit
    • Nico Hartmann's avatar
      Preserve feedback and speculation mode for JSCall · 149e4935
      Nico Hartmann authored
      Changing the target of JSCall nodes (e.g. while lowering higher order calls)
      now preserves feedback and speculation mode to allow further (speculative)
      optimizations. A flag is introduced to mark feedback unrelated to the call
      target after such a transformation. This flag is used to prevent access to
      the feedback without the need to invalidate it.
      
      Bug: v8:9702
      Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64733}
      149e4935
  2. 30 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Optionally apply an offset to stack checks" · b875f466
      Jakob Gruber authored
      This is a reland of 4a16305b
      
      The original CL adjust only one part of the stack check, namely the
      comparison of the stack pointer against the stack limit in generated code.
      There is a second part: Runtime::kStackGuard repeats this check to
      distinguish between a stack overflow and an interrupt request.
      
      This second part in runtime must apply the offset just like in generated
      code. It is implemented in this reland by the StackCheckOffset operator
      and a new StackGuardWithGap runtime function.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      >
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      >
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      >
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      >
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      >
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      Bug: v8:9534, chromium:1000887
      Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64634}
      b875f466
  3. 22 Oct, 2019 4 commits
    • Victor Gomes's avatar
      Reland x3 "[runtime] Remove extension slots from context objects" · dbbdd0ec
      Victor Gomes authored
      Original change's description:
      > [runtime] Remove extension slots from context objects
      >
      > Context objects have an extension slot, which contains further
      > additional data that depends on the type of the context.
      >
      > This CL removes the extension slot from contexts that don't need
      > them, hence reducing memory.
      >
      > The following contexts will still have an extension slot: native,
      > module, await, block and with contexts. See objects/contexts.h for
      > what the slot is used for.
      > The following contexts will not have an extension slot anymore (they
      > were not used before): script, catch and builtin contexts.
      > Eval and function contexts only have the extension slot if they
      > contain a sloppy eval.
      >
      > Bug: v8:9744
      > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64372}
      
      TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      
      Bug: v8:9744
      Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64477}
      dbbdd0ec
    • Clemens Backes's avatar
      Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" · 725e7dd7
      Clemens Backes authored
      This reverts commit 392a1217.
      
      Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747
      
      Original change's description:
      > Reland "Reland "[runtime] Remove extension slots from context objects""
      > 
      > This is a reland of c48096d4
      > 
      > Original change's description:
      > > Reland "[runtime] Remove extension slots from context objects"
      > >
      > > This is a reland of c07c02e1
      > >
      > > Original change's description:
      > > > [runtime] Remove extension slots from context objects
      > > >
      > > > Context objects have an extension slot, which contains further
      > > > additional data that depends on the type of the context.
      > > >
      > > > This CL removes the extension slot from contexts that don't need
      > > > them, hence reducing memory.
      > > >
      > > > The following contexts will still have an extension slot: native,
      > > > module, await, block and with contexts. See objects/contexts.h for
      > > > what the slot is used for.
      > > > The following contexts will not have an extension slot anymore (they
      > > > were not used before): script, catch and builtin contexts.
      > > > Eval and function contexts only have the extension slot if they
      > > > contain a sloppy eval.
      > > >
      > > > Bug: v8:9744
      > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > > > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > > Cr-Commit-Position: refs/heads/master@{#64372}
      > >
      > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      > >
      > > Bug: v8:9744
      > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > Cr-Commit-Position: refs/heads/master@{#64380}
      > 
      > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      > 
      > Bug: v8:9744
      > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64451}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
      
      Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9744
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64453}
      725e7dd7
    • Victor Gomes's avatar
      Reland "Reland "[runtime] Remove extension slots from context objects"" · 392a1217
      Victor Gomes authored
      This is a reland of c48096d4
      
      Original change's description:
      > Reland "[runtime] Remove extension slots from context objects"
      >
      > This is a reland of c07c02e1
      >
      > Original change's description:
      > > [runtime] Remove extension slots from context objects
      > >
      > > Context objects have an extension slot, which contains further
      > > additional data that depends on the type of the context.
      > >
      > > This CL removes the extension slot from contexts that don't need
      > > them, hence reducing memory.
      > >
      > > The following contexts will still have an extension slot: native,
      > > module, await, block and with contexts. See objects/contexts.h for
      > > what the slot is used for.
      > > The following contexts will not have an extension slot anymore (they
      > > were not used before): script, catch and builtin contexts.
      > > Eval and function contexts only have the extension slot if they
      > > contain a sloppy eval.
      > >
      > > Bug: v8:9744
      > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > Cr-Commit-Position: refs/heads/master@{#64372}
      >
      > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      >
      > Bug: v8:9744
      > Change-Id: I0749cc2d8f59940c25841736634a70047116d647
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64380}
      
      TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      
      Bug: v8:9744
      Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@google.com>
      Cr-Commit-Position: refs/heads/master@{#64451}
      392a1217
    • Georg Neis's avatar
      [turbofan] Fix concatenation in parameter printing · 17748912
      Georg Neis authored
      ... and make the printing more consistent.
      
      Bug: v8:9518
      Change-Id: I6e8b595124974ec7f8e5003624bd33d2b0787ac0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864948Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Auto-Submit: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64450}
      17748912
  4. 27 Sep, 2019 1 commit
  5. 12 Sep, 2019 2 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Optionally apply an offset to stack checks" · ba72dc08
      Jakob Gruber authored
      This reverts commit 4a16305b.
      
      Reason for revert: Need to revalidate assumptions behind the CHECK.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      > 
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      > 
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      > 
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      > 
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      > 
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534, chromium:1000887
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63706}
      ba72dc08
    • Jakob Gruber's avatar
      [compiler] Optionally apply an offset to stack checks · 4a16305b
      Jakob Gruber authored
      The motivation behind this change is that the frame size of an optimized
      function and its unoptimized version may differ, and deoptimization
      may thus trigger a stack overflow. The solution implemented in this CL
      is to optionally apply an offset to the stack check s.t. the check
      becomes 'sp - offset > limit'. The offset is applied to stack checks at
      function-entry, and is set to the difference between the optimized and
      unoptimized frame size.
      
      A caveat: OSR may not be fully handled by this fix since we've already
      passed the function-entry stack check. A possible solution would be to
      *not* skip creation of function-entry stack checks for inlinees.
      
      This CL: 1. annotates stack check nodes with the stack check kind, where
      kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      allocates a temporary register to store the result of the 'sp - offset'
      in instruction selection (and switches input registers to 'unique'
      mode). 3. Applies the offset in code generation.
      
      Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      
      Bug: v8:9534,chromium:1000887
      Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63701}
      4a16305b
  6. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored
      This is a reland of 8b89a7c3
      
      Reland after disabling the test getting deadlocked with '--gc_stress' flag.
      The CL was reverted because of the 'wasm/grow-shared-memory' test from
      the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
      the known issue (v8:9221) and the deadlocking test is now disabled (
      https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).
      
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      >
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      >
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      Bug: v8:9489,v8:9221
      Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  7. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored
      This reverts commit 8b89a7c3.
      
      Reason for revert: GC Stress tests timing out.
      See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      > 
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      > 
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9489
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored
      The functionality of the GetIterator bytecode introduced previously is
      now extended from loading the @@iterator property to calling the property
      as well. This change basically absorbs the functionality of additional
      two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      Importantly, this change handles the cases of eager and lazy deoptimization
      in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      This mechanism can work as a template for the future bytecode that require
      handling such inter-bytecode deopt scenario. The tests evaluating the eager
      and lazy deopt scenarios are also included.
      
      Bug: v8:9489
      Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
  8. 26 Aug, 2019 1 commit
  9. 23 Aug, 2019 2 commits
  10. 20 Aug, 2019 1 commit
  11. 09 Aug, 2019 1 commit
  12. 17 Jul, 2019 1 commit
  13. 13 Jun, 2019 1 commit
  14. 24 May, 2019 1 commit
  15. 23 May, 2019 2 commits
  16. 18 Apr, 2019 1 commit
  17. 01 Apr, 2019 1 commit
  18. 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
  19. 12 Mar, 2019 1 commit
  20. 01 Mar, 2019 1 commit
    • Matt Gardner's avatar
      Reland "Optimize `in` operator" · 803ad324
      Matt Gardner authored
      The original was reverted for breaking webkit layout tests:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
      
      It also caused the following clusterfuzz failures:
      
      chromium:935832
      This was a correctness bug due to not properly handling the case of arrays with prototypes other
      than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
      holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
      both in access-assembler and in Turbofan.
      
      chromium:935932
      This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
      code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
      debug builds but in release could show up in different places. This is the bug that caused the
      webkit layout test failure that led to the revert.
      
      Both bugs are fixed by in CL, and tests are added for those cases.
      
      Bug: v8:8733, chromium:935932, chromium:935832
      Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
      Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Matt Gardner <magardn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#59958}
      803ad324
  21. 26 Feb, 2019 1 commit
  22. 25 Feb, 2019 1 commit
  23. 13 Feb, 2019 1 commit
  24. 02 Jan, 2019 1 commit
  25. 24 Oct, 2018 2 commits
    • Benedikt Meurer's avatar
      [turbofan] ReceiverOrNullOrUndefined feedback for JSEqual. · f19c4a59
      Benedikt Meurer authored
      This changes the ReceiverOrOddball feedback on JSStrictEqual to
      ReceiverOrNullOrUndefined feedback, which can also safely be
      consumed by JSEqual (we cannot generally accept any oddball here
      since booleans trigger implicit conversions, unfortunately).
      Thus we replace the previously introduced CheckReceiverOrOddball
      with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
      we will no longer collect Oddball feedback separately.
      
      TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
      a sequence like this:
      
      ```
      left = CheckReceiverOrNullOrUndefined(left);
      right = CheckReceiverOrNullOrUndefined(right);
      result = if ObjectIsUndetectable(left) then
                 ObjectIsUndetectable(right)
               else
                 ReferenceEqual(left, right);
      ```
      
      This significantly improves the peak performance of abstract equality
      with Receiver, Null or Undefined inputs. On the test case outlined in
      http://crbug.com/v8/8356 we go from
      
        naive: 2946 ms.
        tenary: 2134 ms.
      
      to
      
        naive: 2230 ms.
        tenary: 2250 ms.
      
      which corresponds to a 25% improvement on the abstract equality case.
      For regular code this will probably yield more performance, since we
      get rid of the JSEqual operator, which might have arbitrary side
      effects and thus blocks all kinds of TurboFan optimizations. The
      JSStrictEqual case is slightly slower now, since it has to rule out
      booleans as well (even though that's not strictly necessary, but
      consistency is key here).
      
      This way developers can safely use `a == b` instead of doing a dance
      like `a == null ? b == null : a === b` (which is what dart2js does
      right now) when both `a` and `b` are known to be Receiver, Null or
      Undefined. The abstract equality is not only faster to parse than
      the tenary, but also generates a shorter bytecode sequence. In the
      test case referenced in http://crbug.com/v8/8356 the bytecode for
      `naive` is
      
      ```
      StackCheck
      Ldar a1
      TestEqual a0, [0]
      JumpIfFalse [5]
      LdaSmi [1]
      Return
      LdaSmi [2]
      Return
      ```
      
      which is 14 bytes, whereas the `tenary` function generates
      
      ```
      StackCheck
      Ldar a0
      TestUndetectable
      JumpIfFalse [7]
      Ldar a1
      TestUndetectable
      Jump [7]
      Ldar a1
      TestEqualStrict a0, [0]
      JumpIfToBooleanFalse [5]
      LdaSmi [1]
      Return
      LdaSmi [2]
      Return
      ```
      
      which is 24 bytes. So the `naive` version is 40% smaller and requires
      fewer bytecode dispatches.
      
      Bug: chromium:898455, v8:8356
      Change-Id: If3961b2518b4438700706b3bd6071d546305e233
      Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56948}
      f19c4a59
    • Benedikt Meurer's avatar
      [turbofan] Collect and consume (ReceiverOr)Oddball feedback for StrictEqual. · 8f00d61d
      Benedikt Meurer authored
      This CL introduces proper Oddball and ReceiverOrOddball states for the
      CompareOperationFeedback, and updates the StrictEqual IC to collect this
      feedback as well. Previously it would not collect Oddball feedback, not
      even in the sense of NumberOrOddball, since that's not usable for the
      SpeculativeNumberEqual.
      
      The new feedback is handled via newly introduced CheckReceiverOrOddball
      and CheckOddball operators in TurboFan, introduced by JSTypedLowering.
      Just like with the Receiver feedback, it's enough to check one side and
      do a ReferenceEqual afterwards, since strict equal can only yield true
      if both sides refer to the same instance.
      
      This improves the benchmark mentioned in http://crbug.com/v8/8356 from
      
        naive: 2950 ms.
        tenary: 2456 ms.
      
      to around
      
        naive: 2996 ms.
        tenary: 2192 ms.
      
      which corresponds to a roughly 10% improvement in the case for the
      tenary pattern, which is currently used by dart2js. In real world
      scenarios this will probably help even more, since TurboFan is able
      to optimize across the strict equality, i.e. there's no longer a stub
      call forcibly spilling all registers that are live across the call.
      
      This new feedback will be used as a basis for the JSEqual support for
      ReceiverOrOddball, which will allow dart2js switching to the shorter
      a==b form, at the same peak performance.
      
      Bug: v8:8356
      Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2
      Reviewed-on: https://chromium-review.googlesource.com/c/1297309Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56925}
      8f00d61d
  26. 11 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce dedicated JSAsyncFunctionObject. · a63987a4
      Benedikt Meurer authored
      This JSAsyncFunctionObject represents the implicit generator object
      inside of async functions, and also holds the outer promise for the
      async functions. This in turn allows us to get rid of the .promise
      in the Parser / BytecodeGenerator completely, and will make it
      possible to build zero-cost async stack traces independent of the
      concrete synchronous part of the stack frame (which currently breaks
      in Node.js).
      
      In the bytecode all the async function operations now take this new
      JSAsyncFunctionObject instead of passing both the .generator_object
      and the .promise, which further simplifies and shrinks the bytecode.
      It also reduces the size of async function frames, potentially making
      the suspend/resume cheaper.
      
      This also changes `await` to use intrinsics instead of calling to
      special JSFunctions on the native context, and thus reduces the size of
      the native contexts.
      
      Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
      to TurboFan.
      
      Bug: v8:7253, v8:7522
      Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
      Ref: nodejs/node#11865
      Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
      Reviewed-on: https://chromium-review.googlesource.com/c/1273049
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56554}
      a63987a4
  27. 10 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored
      This change introduces new intrinsics used to desugar async functions
      in the Parser and the BytecodeGenerator, namely we introduce a new
      %_AsyncFunctionEnter intrinsic that constructs the generator object
      for the async function (and in the future will also create the outer
      promise for the async function). This generator object is internal
      and never escapes to user code, plus since async functions don't have
      a "prototype" property, we can just a single map here instead of tracking
      the prototype/initial_map on every async function. This saves one word
      per async function plus one initial_map per async function that was
      invoked at least once.
      
      We also introduce two new intrinsics %_AsyncFunctionReject, which
      rejects the outer promise with the caught exception, and another
      %_AsyncFunctionResolve, which resolves the outer promise with the
      right hand side of the `return` statement. These functions also perform
      the DevTools part of the job (aka popping from the promise stack and
      sending the debug event). This allows us to get rid of the implicit
      try-finally from async functions completely; because the finally
      block only called to the %AsyncFunctionPromiseRelease builtin, which
      was used to inform DevTools.
      
      In essence we now turn an async function like
      
      ```js
      async function f(x) { return await bar(x); }
      ```
      
      into something like this (in Parser and BytecodeGenerator respectively):
      
      ```
      function f(x) {
        .generator_object = %_AsyncFunctionEnter(.closure, this);
        .promise = %AsyncFunctionCreatePromise();
        try {
          .tmp = await bar(x);
          return %_AsyncFunctionResolve(.promise, .tmp);
        } catch (e) {
          return %_AsyncFunctionReject(.promise, e);
        }
      }
      ```
      
      Overall the bytecode for async functions gets significantly shorter
      already (and will get even shorter once we put the outer promise into
      the async function generator object). For example the bytecode for a
      simple async function
      
      ```js
      async function f(x) { return await x; }
      ```
      
      goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
      is in particular due to the simplification around the try-finally
      removal.
      
      Overall this seems to improve the doxbee-async-es2017-native test by
      around 2-3%. On the test case mentioned in v8:8276 we go from
      1124ms to 441ms, which corresponds to a 60% reduction in total
      execution time!
      
      Tbr: marja@chromium.org
      Bug: v8:7253, v8:7522, v8:8276
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1269041
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
  28. 27 Sep, 2018 1 commit
  29. 26 Sep, 2018 1 commit
  30. 21 Sep, 2018 1 commit
  31. 11 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Reduce overhead of megamorphic property accesses. · a15ad0d3
      Benedikt Meurer authored
      We had an optimization in Crankshaft where we would call into the
      megamorphic handler stub directly if an inline cache was already
      found to be megamorphic when it hit the optimizing compiler. This
      way we could avoid the dispatch overhead when we know that there's
      no point in checking for the other states anyways. However we somehow
      missed to port this optimization to TurboFan.
      
      Now this change introduces support to call into LoadIC_Megamorphic and
      KeyedLoadIC_Megamorphic directly (plus the trampoline versions), which
      saves quite a lot of overhead for the cases where the map/name pair is
      found in the megamorphic stub cache, and it's quite a simple change. We
      can later extend this to also handle the StoreIC and KeyedStoreIC cases
      if that turns out to be beneficial.
      
      This improves the score on the Octane/TypeScript test by around ~2%
      and the TypeScript test in the web-tooling-benchmark by around ~4%. On
      the ARES-6 Air test the steady state mean improves by 2-4%, and on the
      ARES-6 ML test the steady state mean seems to also improve by 1-2%, but
      that might be within noise.
      
      On a micro-benchmark that just runs `o.x` in a hot loop on a set of 9
      different objects, which all have `x` as the first property and are
      all in fast mode, we improve by around ~30%, and are now almost on par
      with JavaScriptCore.
      
      Bug: v8:6344, v8:6936
      Change-Id: Iaa4c6e34c37e78da217ee75f32f6acc95a834250
      Reviewed-on: https://chromium-review.googlesource.com/1215623Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55803}
      a15ad0d3
  32. 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