1. 11 Aug, 2020 1 commit
  2. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  3. 22 Jul, 2020 1 commit
  4. 20 Jul, 2020 1 commit
  5. 14 Jul, 2020 2 commits
  6. 17 Jun, 2020 1 commit
    • Georgia Kouveli's avatar
      [arm64][cfi] Skip authenticating return addresses in the profiler · bf383a87
      Georgia Kouveli authored
      The SafeStackFrameIterator, used in the profiler, sometimes uses the
      link register instead of a return address stored on the stack, to get
      more accurate results. This happens in particular for bytecode handlers
      that do not create a stack frame. Authentication of PC for those frames
      would fail in the SafeStackFrameIterator, as the "PC address" would not
      point to a stack location with a signed return address, but instead to
      a member of the SafeStackFrameIterator class where the value of the link
      register was stored. We address this by skipping authentication of PCs
      in the profiler.
      
      Bug: v8:10026
      Change-Id: I331c6c68e703db766be1891efffa69c2f9794e8a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242954Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#68388}
      bf383a87
  7. 13 May, 2020 1 commit
  8. 11 May, 2020 1 commit
  9. 08 May, 2020 1 commit
  10. 06 May, 2020 1 commit
  11. 21 Apr, 2020 1 commit
  12. 03 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Reorganize source position lookup · 3aedafbb
      Clemens Backes authored
      Instead of two copies of the lookup code in frames.cc and wasm-debug.cc,
      put one lookup method on the WasmCode. This is where it belongs really,
      since the WasmCode is the main input to the function (besides the
      offset).
      
      Also refactor how source positions are computed in WasmCompiledFrame.
      Avoid going through the summary, which is unneccessarily complex. This
      also adds another {byte_offset} accessor which can be used for
      debugging.
      
      Bug: v8:10235
      Change-Id: I5c545ee302754b86009f09bedc5ff6e39ba664f6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135726Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66991}
      3aedafbb
  13. 16 Mar, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Load register values from DebugBreak frame · ae03752f
      Clemens Backes authored
      This implements inspection of live registers on breakpoints in Liftoff.
      To that end, the frame pointer of the WasmDebugBreak frame is remembered
      when iterating the stack. Based on a platform-specific implementation of
      {WasmDebugBreakFrameConstants}, the offset of the respective register
      within that frame is computed, and the value is read from the frame.
      
      As a drive-by, the wasm debug side table is storing register codes as
      liftoff codes, which can also store register pairs (needed for i64 on
      32-bit platforms, and for SIMD, which is not supported yet).
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66719}
      ae03752f
    • Clemens Backes's avatar
      [wasm] Fix registers spilled in DebugBreak frame · e47f9a9d
      Clemens Backes authored
      The set of registers to spill was wrong. Instead of spilling wasm
      parameter registers (like the WasmCompileLazy builtin), we should spill
      all registers that are being used as Liftoff cache registers.
      This CL defines platform-specific WasmDebugBreakFrameConstants which
      hold the set of registers to spill. This set is used in the builtin, and
      will later be used for inspecting the spilled registers.
      
      In order to iterate bit sets more easily in both direction (MSB to LSB
      or LSB to MSB), we add a base::bits::IterateBits{,Backwards} method
      which provides the respective iterators.
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I73ecbdff9b29e244c478b404063c0c9ee25bc821
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102570Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66715}
      e47f9a9d
  14. 02 Mar, 2020 2 commits
  15. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored
      This is a reland of 137bfe47
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      Bug: v8:10026
      Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  16. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored
      This reverts commit 137bfe47.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
      
      Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored
      This change uses the Arm v8.3 pointer authentication instructions in
      order to protect return addresses stored on the stack.  The generated
      code signs the return address before storing on the stack and
      authenticates it after loading it. This also changes the stack frame
      iterator in order to authenticate stored return addresses and re-sign
      them when needed, as well as the deoptimizer in order to sign saved
      return addresses when creating new frames. This offers a level of
      protection against ROP attacks.
      
      This functionality is enabled with the v8_control_flow_integrity flag
      that this CL introduces.
      
      The code size effect of this change is small for Octane (up to 2% in
      some cases but mostly much lower) and negligible for larger benchmarks,
      however code size measurements are rather noisy. The performance impact
      on current cores (where the instructions are NOPs) is single digit,
      around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      cores than for little cores.
      
      Bug: v8:10026
      Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  17. 10 Feb, 2020 1 commit
  18. 21 Jan, 2020 1 commit
    • Clemens Backes's avatar
      Move decoded asm.js offset table off-heap · 87f09404
      Clemens Backes authored
      The asm.js offset table exists in two forms: Delta-encoded in a byte
      array, as generated during asm translation, and decoded, for faster
      lookup.
      This CL moves the encoded version from the {AsmWasmData} and
      {WasmModuleObject} to the {WasmModule}, and stores it off-heap in a C++
      array instead of a {ByteArray}.
      Also, it moves the decoded version off-heap by storing it in a C++ data
      structure that makes lookup easy, instead of encoding it again in
      another {ByteArray}.
      
      This change is a nice refactoring in itself, but it also prepares adding
      more information to the offset table. For reconstructing the source code
      of an asm.js function, we will need to store the start and end offsets
      of the whole function as well (see linked bug).
      
      R=jkummerow@chromium.org
      
      Bug: chromium:667678
      Change-Id: I79b789c3122dd8ba803cedc6bfdcc3d4b1fa0fd4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011108
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65900}
      87f09404
  19. 27 Dec, 2019 1 commit
  20. 03 Dec, 2019 1 commit
  21. 22 Nov, 2019 1 commit
  22. 04 Nov, 2019 1 commit
    • Dan Elphick's avatar
      Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 352bbb12
      Dan Elphick authored
      This is a reland of 855591a5
      
      Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
      Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
      
      Original change's description:
      > Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      >
      > Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
      >
      > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      >
      > Creates an allow-list of builtins that can still go in code_space
      > including all TFJ builtins and a small manual list that should be pared
      > down in the future.
      >
      > For builtins that go in RO_SPACE a Code object is created that contains an
      > immediate trap instruction. Generally these Code objects are still no
      > smaller than CODE_SPACE Code objects because of the Code object alignment
      > requirements. This will hopefully be addressed in a follow-up CL either by
      > relaxing them or removing the instruction stream completely.
      >
      > In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
      > increases by the same amount.
      >
      > Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64700}
      
      Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64728}
      352bbb12
  23. 31 Oct, 2019 2 commits
  24. 25 Oct, 2019 2 commits
  25. 24 Oct, 2019 2 commits
  26. 18 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "[builtins] Move non-JS linkage builtins code objects into RO_SPACE" · f1ebde88
      Sathya Gunasekaran authored
      This reverts commit 83f8464f.
      
      Reason for revert: speculative revert for blink linux failure
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/1272
      
      Original change's description:
      > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      > 
      > Creates an allow-list of builtins that can still go in code_space
      > including all TFJ builtins and a small manual list that should be pared
      > down in the future.
      > 
      > For builtins that go in RO_SPACE a Code object is created that contains
      > no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
      > but is there to allow the runtime to continue to work since it expects
      > a Code object.
      > 
      > This reduces code_space from ~152k to ~40k (-112k) and increases
      > read_only_space from 33k to 108k (+75k) in the snapshot.
      > 
      > Bug: v8:7464, v8:9821, v8:9338, v8:8127
      > Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64377}
      
      TBR=mstarzinger@chromium.org,jgruber@chromium.org,delphick@chromium.org
      
      Change-Id: I4cf38e9370280acdd2de718ca527776ebc509003
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7464, v8:9821, v8:9338, v8:8127
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868621Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64383}
      f1ebde88
    • Dan Elphick's avatar
      [builtins] Move non-JS linkage builtins code objects into RO_SPACE · 83f8464f
      Dan Elphick authored
      Creates an allow-list of builtins that can still go in code_space
      including all TFJ builtins and a small manual list that should be pared
      down in the future.
      
      For builtins that go in RO_SPACE a Code object is created that contains
      no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
      but is there to allow the runtime to continue to work since it expects
      a Code object.
      
      This reduces code_space from ~152k to ~40k (-112k) and increases
      read_only_space from 33k to 108k (+75k) in the snapshot.
      
      Bug: v8:7464, v8:9821, v8:9338, v8:8127
      Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64377}
      83f8464f
  27. 08 Oct, 2019 1 commit
  28. 26 Sep, 2019 1 commit
  29. 13 Sep, 2019 1 commit
  30. 11 Sep, 2019 1 commit
  31. 05 Sep, 2019 1 commit
  32. 22 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Track the maximal unoptimized frame size" · 95e26e49
      Jakob Gruber authored
      This is a reland of 1e472c42
      
      No change, this was a speculative revert to unblock the roll.
      
      TBR=jgruber
      
      Original change's description:
      > [compiler] Track the maximal unoptimized frame size
      >
      > This is another step towards considering the unoptimized frame size in
      > stack checks within optimized code.
      >
      > With the changes in this CL, we now keep track of the maximal
      > unoptimized frame size of the function that is currently being
      > compiled. An optimized function may inline multiple unoptimized
      > functions, so a single optimized frame can deopt to multiple
      > frames. The real frame size thus differs in different parts of the
      > optimized function.
      >
      > We only care about the maximal frame size, which we calculate
      > conservatively as an over-approximation, and track in
      > InstructionSelector::max_unoptimized_frame_height_ for now. In future
      > work, this value will be passed on to codegen, where it will be
      > applied as an offset to the stack pointer during the stack check.
      >
      > (The motivation behind this is to avoid stack overflows through deopts,
      > caused by size differences between optimized and unoptimized frames.)
      >
      > Note that this offset only ensure that the topmost optimized frame can
      > deopt without overflowing the stack limit. That's fine, because we only
      > deopt optimized frames one at a time. Other (non-topmost) frames are
      > only deoptimized once they are returned to.
      >
      > Drive-by: Print variable and total frame height in --trace-deopt.
      >
      > Bug: v8:9534
      > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63330}
      
      Bug: v8:9534
      Change-Id: I686f200e7be1f419e23e50789e11607a0b2886d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1766645
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63356}
      95e26e49