1. 27 May, 2019 2 commits
  2. 24 May, 2019 1 commit
  3. 23 May, 2019 2 commits
  4. 22 May, 2019 1 commit
  5. 21 May, 2019 1 commit
  6. 20 May, 2019 1 commit
  7. 17 May, 2019 2 commits
  8. 16 May, 2019 1 commit
  9. 15 May, 2019 1 commit
  10. 02 May, 2019 2 commits
    • Seth Brenith's avatar
      Touch guard pages when allocating stack frames · df8548cd
      Seth Brenith authored
      On Windows, expanding the stack by more than 4 KB at a time can cause
      access violations. This change fixes a few known cases (and includes
      unit tests for those), and attempts to make stack expansion more
      consistent overall by using the AllocateStackSpace helper method
      everywhere we can, even when the offset is a small constant.
      
      On arm64, there was already a consistent method for stack pointer
      manipulation using the Claim and Drop methods, so Claim is updated to
      touch every page.
      
      Bug: v8:9017
      Change-Id: I2dbbceeebbdefaf45803e9b621fe83f52234a395
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570666
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61186}
      df8548cd
    • Pierre Langlois's avatar
      [arm][arm64] Do not allocate temp registers for the write barrier. · 3f1a59f4
      Pierre Langlois authored
      Improve code generation for stores with write barriers slightly by using the
      assembler's dedicated scratch registers (x16 and x17 on Arm64, ip on Arm)
      instead of allocating temporaries.
      
      To do this, we've done two things:
      
        - Use ip as a scratch register when loading page flags.
      
        - TurboAssembler::CallRecordWriteStub() now takes the offset of the slot
          that's written to rather than its address, removing the need to allocate a
          temporary register for it.
      
      In essence, we've gone from:
      
      ```
      ;; Do the store.
      stur x19, [x9, #15]
      ;; Check *destination* object page flags and jump out-of-line.
      and x4, x9, #0xfffffffffff80000
      ldr x4, [x4, #8]
      tbnz x4, #2, #+0x1e7c
      |     ;; Check *source* object page flags.
      | `-> and x4, x19, #0xfffffffffff80000
      |     ldr x4, [xM, #8]
      |,--- tbz x4, #1, #-0x1e80
      |     ;; Compute address of slot.
      |     add x5, x9, #0xf (15)
      |     ;; Setup arguments to RecordWrite
      |     stp x2, x3, [sp, #-32]!
      |     stp x4, lr, [sp, #16]
      |     stp x0, x1, [sp, #-16]!
      |     mov x0, x9 ;; Object address in x9
      |     mov x1, x5 ;; Slot address in x5
      |     movz x2, #0x0
      |     movz x3, #0x100000000
      |     ;; Call RecordWrite
      |     ldr x16, pc+2056
      |     blr x16
      ```
      
      Which allocates x4 and x5 as temporaries.
      
      To:
      
      ```
      stur x19, [x9, #15]
      and x16, x9, #0xfffffffffff80000 ;; Using x16 instead of allocating x4.
      ldr x16, [x16, #8]
      tbnz x16, #2, #+0x1e7c
      | `-> and x16, x19, #0xfffffffffff80000
      |     ldr x16, [xM, #8]
      |,--- tbz x16, #1, #-0x1e80
      |     stp x2, x3, [sp, #-32]!
      |     stp x4, lr, [sp, #16]
      |     stp x0, x1, [sp, #-16]!
      |     mov x0, x9            ;; Object address still in x9.
      |     add x1, x9, #0xf (15) ;; Compute the slot address directly.
      |     movz x2, #0x0
      |     movz x3, #0x100000000
      |     ldr x16, pc+2056
      |     blr x16
      ```
      
      Finally, `RecordWriteField()` does not need an extra scratch register anymore.
      
      Change-Id: Icb71310e7b8ab1ca83ced250851456166b337d00
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505793
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61153}
      3f1a59f4
  11. 08 Apr, 2019 1 commit
  12. 01 Apr, 2019 1 commit
  13. 25 Mar, 2019 2 commits
  14. 18 Mar, 2019 1 commit
  15. 15 Mar, 2019 1 commit
  16. 05 Mar, 2019 1 commit
  17. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [objects] Free one bit in the SharedFunctionInfo::flags. · 591408cb
      Benedikt Meurer authored
      We'll need one bit in the SharedFunctionInfo::flags to record whether
      it's safe to skip arguments adaptor frames (for v8:8895), so this
      just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
      redundant, since the same information is already available in the
      SharedFunctionInfo::FunctionKindBits, and most places in the code
      use that already, with the exception of the JSConstructStubGeneric
      builtin.
      
      This changes the JSConstructStubGeneric builtin to just check the
      function kind instead of testing the explicit bit, which also makes
      this more consistent. It seems like there's not much overhead to
      that, doing an additional bitmasking plus two comparisons instead
      of one. This shouldn't really matter since invocation and execution
      of the constructors is going to dominate and optimized code inlines
      all of this anyways. If this turns out to affect performance, we
      can still look into encoding the FunctionKindBits more cleverly.
      
      Drive-by-fix: Move the FunctionKindBits first in the flags to avoid
      the shift when accessing the function kind. This seems logic, since
      for the actual boolean bit fields it doesn't matter where they are
      in the flags, whereas for the function kind this saves one shift.
      
      Bug: v8:8834, v8:8895
      Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306
      Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59821}
      591408cb
  18. 21 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete representations. · adb7e37b
      Benedikt Meurer authored
      In the Crankshaft days we (mis)used the Representation to also express
      the various internal representations that the compiler understands. But
      with TurboFan we now have proper MachineRepresentation and MachineType,
      which do that independently. So there's no need to have this in the
      Representation class anymore, and instead the Representation class only
      needs to deal with the field representations.
      
      Bug: v8:8749, v8:8834, v8:8865
      Change-Id: I34ea9558b5fdf20d6c7939b52762eaffd4316b06
      Reviewed-on: https://chromium-review.googlesource.com/c/1479954
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59750}
      adb7e37b
  19. 15 Feb, 2019 1 commit
  20. 05 Feb, 2019 1 commit
  21. 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
  22. 08 Jan, 2019 1 commit
    • Ross McIlroy's avatar
      [Deopt] Remove jump table in prologue of deopt entries. · 4ab96a9a
      Ross McIlroy authored
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58636}
      4ab96a9a
  23. 21 Dec, 2018 1 commit
  24. 17 Dec, 2018 2 commits
    • Jakob Gruber's avatar
      [nojit] Change builtin pointers to use Smis underneath · fa3cbf60
      Jakob Gruber authored
      This changes Torque's builtin pointers to use a Smi representation
      underneath instead of storing the Code target object. Callsites look
      up the target entry point through IsolateData::builtin_entry_table.
      
      The notable effect of this CL is that builtin pointer calls no longer
      call any on-heap Code.
      
      Bug: v8:7777
      Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63
      Reviewed-on: https://chromium-review.googlesource.com/c/1379880
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58286}
      fa3cbf60
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored
      Currently, Torque's builtin pointers store a Code target underneath and
      callsites generate a kArchCallCodeObject opcode. When embedded builtins
      are enabled, the call thus first calls the on-heap trampoline, which
      finally jumps to the target off-heap builtin code.
      
      This will no longer be possible in jitless mode, since on-heap code must
      not be executable.
      
      As a step towards changing the way builtin pointers are called
      (function pointers will hold the builtin index as a Smi, and callsites
      look up the off-heap target address and jump there), this CL adds a
      dedicated opcode for builtin pointer calls to the compiler pipeline.
      
      The calling mechanism itself is unchanged, changes there will happen
      in a follow-up.
      
      Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
      
      Bug: v8:7777
      Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
      Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  25. 11 Dec, 2018 1 commit
  26. 07 Dec, 2018 4 commits
  27. 05 Dec, 2018 1 commit
  28. 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
  29. 28 Nov, 2018 2 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