1. 15 Feb, 2019 1 commit
  2. 17 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      Use forwarding constructors for MacroAssembler · edab9a20
      Clemens Hammacher authored
      and TurboAssembler. Instead of listing all the different combinations
      of arguments (which is one more now, temporarily), just forward all
      arguments down via MacroAssembler and TurboAssembler to
      TurboAssemblerBase.
      Interestingly, this requires more specific types sometimes (int instead
      of size_t), since further down the forwarding chain, the compiler does
      not recognize any more that the value is a constant, and emits a
      warning about a possibly truncating implicit conversion.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689, v8:8562
      Change-Id: Ifd13d2210ee64251c0075c0d9b68cacd5107d9ab
      Reviewed-on: https://chromium-review.googlesource.com/c/1414913Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58869}
      edab9a20
  3. 11 Jan, 2019 1 commit
  4. 09 Jan, 2019 1 commit
    • Predrag Rudic's avatar
      MIPS[64]: Port '[Deopt] Remove jump table in prologue of deopt entries.' · b0dc60f6
      Predrag Rudic authored
      Port commit 4ab96a9a
      
      Original message:
      > Remove the use of a jump table in the prologue of the deopt entries
      > and instead pass the bailout id explicitly in a register when calling
      > the deopt entry routine from optimized code. This unifies the logic
      > with the way the Arm64 code works. It saves the following amount of
      > memory in code stubs:
      >
      >  - arm:  384KB
      >  - ia32: 480KB
      >  - x64:  240KB
      >
      > This could be offset by a slight increase in the size of optimized code
      > for loading the immediate, however this impact should be minimal and
      > will scale with the maximum number of bailout ids (e.g., the size of
      > code will increase by one instruction per bailout id on Arm, therefore
      > ~98,000 bailouts will be needed before the overhead is greater than
      > the current fixed table size).
      >
      > Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25
      > Reviewed-on: https://chromium-review.googlesource.com/c/1398224
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58636}
      
      Change-Id: I4d070b90ebd4f9d4e82eaa74fe6d41c3a39d93e8
      Reviewed-on: https://chromium-review.googlesource.com/c/1400848Reviewed-by: 's avatarSreten Kovacevic <skovacevic@wavecomp.com>
      Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
      Cr-Commit-Position: refs/heads/master@{#58655}
      b0dc60f6
  5. 24 Dec, 2018 1 commit
    • Aleksandar Rikalo's avatar
      [mips] InterpreterEntryTrampoline improvement · 0f1b6112
      Aleksandar Rikalo authored
      Logic is added to InterpreterEntryTrampoline to detect flushed functions,
      and enter CompileLazy instead. Get the bytecode array from the function
      object and load it. The bytecode array could have been flushed from the
      shared function info, if so, call into CompileLazy.
      
      This fixes:
      
         cctest/test-heap/TestBytecodeFlushing
         cctest/test-heap/TestOptimizeAfterBytecodeFlushingCandidate
         debugger/debug/lazy-deopt-then-flush-bytecode
      
      [mips] Macro-assembler fix
      
      Fix massive failing of tests after fa3cbf60.
      
      Change-Id: Ic1978b5233eefc743fd7b020f65153630ffa281f
      Reviewed-on: https://chromium-review.googlesource.com/c/1388528Reviewed-by: 's avatarSreten Kovacevic <skovacevic@wavecomp.com>
      Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
      Cr-Commit-Position: refs/heads/master@{#58463}
      0f1b6112
  6. 19 Dec, 2018 1 commit
  7. 17 Dec, 2018 3 commits
  8. 14 Dec, 2018 1 commit
  9. 11 Dec, 2018 1 commit
  10. 07 Dec, 2018 3 commits
  11. 05 Dec, 2018 1 commit
  12. 30 Nov, 2018 1 commit
  13. 29 Nov, 2018 2 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 6c8b4102
      Peter Marshall authored
      This is a reland of d5f4a33e
      Landing with test disabled for now.
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      >
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      >
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      >
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      >
      > TBR=v8-mips-ports@googlegroups.com
      >
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=v8-mips-ports@googlegroups.com
      TBR=jgruber@chromium.org
      
      Bug: v8:8464, v8:7202
      Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf
      Reviewed-on: https://chromium-review.googlesource.com/c/1354466
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57935}
      6c8b4102
    • Michael Achenbach's avatar
      Revert "Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"" · 76786104
      Michael Achenbach authored
      This reverts commit ddaa1f0a.
      
      Reason for revert:
      Still flaky on windows. Maybe reland and keep skipped on windows?
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826
      
      Original change's description:
      > Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
      > 
      > This is a reland of d5f4a33e
      > 
      > Original change's description:
      > > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      > >
      > > Before fast C calls, store the current FP and PC on the isolate. When
      > > iterating frames in SafeStackFrameIterator, check if these fields are
      > > set and start iterating at the calling frame's FP instead of the current
      > > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > > frame.
      > >
      > > This change makes stack samples that occur within 'Fast-C-Calls'
      > > iterable, meaning we can properly attribute ticks within the JS caller.
      > >
      > > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > > such call on the stack at a time, allowing us to store the FP on the
      > > isolate rather than the stack.
      > >
      > > TBR=v8-mips-ports@googlegroups.com
      > >
      > > Bug: v8:8464, v8:7202
      > > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#57896}
      > 
      > TBR=v8-mips-ports@googlegroups.com
      > TBR=jgruber@chromium.org
      > 
      > Bug: v8:8464, v8:7202
      > Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
      > Reviewed-on: https://chromium-review.googlesource.com/c/1354042
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57912}
      
      TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
      
      Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8464, v8:7202
      Reviewed-on: https://chromium-review.googlesource.com/c/1354461Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57925}
      76786104
  14. 28 Nov, 2018 3 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · ddaa1f0a
      Peter Marshall authored
      This is a reland of d5f4a33e
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      >
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      >
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      >
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      >
      > TBR=v8-mips-ports@googlegroups.com
      >
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=v8-mips-ports@googlegroups.com
      TBR=jgruber@chromium.org
      
      Bug: v8:8464, v8:7202
      Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
      Reviewed-on: https://chromium-review.googlesource.com/c/1354042Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57912}
      ddaa1f0a
    • Maya Lekova's avatar
      Revert "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 2f530d5c
      Maya Lekova authored
      This reverts commit d5f4a33e.
      
      Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      > 
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      > 
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      > 
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      > 
      > TBR=v8-mips-ports@googlegroups.com
      > 
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
      
      Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8464, v8:7202
      Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57899}
      2f530d5c
    • Peter Marshall's avatar
      [cpu-profiler] Fix stack iterability for fast C calls with no exit frame · d5f4a33e
      Peter Marshall authored
      Before fast C calls, store the current FP and PC on the isolate. When
      iterating frames in SafeStackFrameIterator, check if these fields are
      set and start iterating at the calling frame's FP instead of the current
      FP, which will be in C++ code. We need to do this because c_entry_fp is
      not set on the Isolate for Fast-C-Calls because we don't build an exit
      frame.
      
      This change makes stack samples that occur within 'Fast-C-Calls'
      iterable, meaning we can properly attribute ticks within the JS caller.
      
      Fast-C-Calls can't call back into JS code, so we can only ever have one
      such call on the stack at a time, allowing us to store the FP on the
      isolate rather than the stack.
      
      TBR=v8-mips-ports@googlegroups.com
      
      Bug: v8:8464, v8:7202
      Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
      Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57896}
      d5f4a33e
  15. 26 Nov, 2018 1 commit
  16. 16 Nov, 2018 2 commits
  17. 14 Nov, 2018 1 commit
  18. 09 Nov, 2018 1 commit
  19. 08 Nov, 2018 1 commit
  20. 07 Nov, 2018 2 commits
  21. 05 Nov, 2018 1 commit
  22. 30 Oct, 2018 1 commit
  23. 25 Oct, 2018 1 commit
  24. 19 Oct, 2018 1 commit
    • Predrag Rudic's avatar
      MIPS[64]: Port: [async] Introduce dedicated JSAsyncFunctionObject. · 44142530
      Predrag Rudic authored
      Port commit a63987a4
      
      Original message:
      >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: Sathya Gunasekaran <gsathya@chromium.org>
      >Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      >Reviewed-by: Maya Lekova <mslekova@chromium.org>
      >Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      >Cr-Commit-Position: refs/heads/master@{#56554}
      
      Change-Id: I5a11bd31bf2aac2e2b94779fa03b85ee88d7dbc4
      Reviewed-on: https://chromium-review.googlesource.com/c/1288811Reviewed-by: 's avatarIvica Bogosavljevic <ibogosavljevic@wavecomp.com>
      Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
      Cr-Commit-Position: refs/heads/master@{#56818}
      44142530
  25. 17 Oct, 2018 1 commit
  26. 10 Oct, 2018 1 commit
  27. 20 Sep, 2018 2 commits
  28. 03 Sep, 2018 1 commit
    • jgruber's avatar
      Remove isolate parameter from RecordWrite builtin · 62766423
      jgruber authored
      The isolate can be efficiently loaded through other means: either as a
      root-relative load (if embedded builtins are enabled), or as an embedded
      external reference (i.e. the absolute pointer is included in the
      instruction stream) otherwise.
      
      The generated code should be at least as fast as previously. On x64
      (with embedded builtins):
      
      Before:
       // Register moves in prologue:
       0x7f47a6b4860a     a  488955e0       REX.W movq [rbp-0x20],rdx
       // And the load from a stack slot at each use-site.
       0x7f47a6b486f2    f2  488b7de0       REX.W movq rdi,[rbp-0x20]
      
      After:
       // Each use-site just loads a root-relative offset.
       0x7f1645fcc6ce    ee  498dbd38ffffff REX.W leaq rdi,[r13-0xc8]
      
      On ia32 (no embedded builtins), before:
       0x5c608930    10  8955f0         mov [ebp-0x10],edx
       0x5c6089fb    db  891424         mov [esp],edx
      
      After:
       0x41d0898d    8d  b80033b156     mov eax,0x56b13300
      
      Removal reduces register pressure, and frees up ebx as the root register
      on ia32.
      
      Note that the set of allocatable registers was only reduced on ia32 to
      exclude the root register.
      
      Bug: v8:6666
      Change-Id: I14e401e2823c82042c76acae10c3c935b9982993
      Reviewed-on: https://chromium-review.googlesource.com/1201586
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55587}
      62766423
  29. 13 Aug, 2018 1 commit
  30. 10 Aug, 2018 1 commit