1. 21 May, 2019 1 commit
  2. 20 May, 2019 5 commits
  3. 17 May, 2019 3 commits
  4. 16 May, 2019 2 commits
  5. 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
  6. 30 Apr, 2019 1 commit
  7. 25 Apr, 2019 1 commit
  8. 16 Apr, 2019 1 commit
  9. 08 Apr, 2019 2 commits
  10. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored
      Allocate feedback vectors lazily when the function's interrupt budget has
      reached a specified threshold. This cl introduces a new field in the
      ClosureFeedbackCellArray to track the interrupt budget for allocating
      feedback vectors. Using the interrupt budget on the bytecode array could
      cause problems when there are closures across native contexts and we may
      delay allocating feedback vectors in one of them causing unexpected
      performance cliffs. In the long term we may want to remove interrupt budget
      from bytecode array and use context specific budget for tiering up decisions
      as well.
      
      Bug: v8:8394
      Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  11. 20 Mar, 2019 1 commit
  12. 12 Mar, 2019 1 commit
  13. 11 Mar, 2019 1 commit
  14. 01 Mar, 2019 1 commit
    • Georgia Kouveli's avatar
      [arm64] Port the skipping of arguments adaptor frames. · cc5808cd
      Georgia Kouveli authored
      This is a port of the improvements to the ArgumentsAdaptorTrampoline
      that previously landed for x64. It skips the arguments adaptor frame
      creation if the callee cannot observe the actual arguments (as indicated
      by the "is_safe_to_skip_arguments_adaptor" bit on the SharedFunctionInfo),
      and instead just massages the current stack frame appropriately (either
      by pushing more undefineds in case of under application, or by removing
      the superfluous arguments in case of over application).
      
      Due to the 16 byte stack alignment requirement on arm64, we only skip
      the arguments adaptor frame creation when the difference between the
      expected and the actual argument number is even. When it is odd, we
      would still need to copy the actual arguments in the existing frame to
      account for the padding, which would defeat the point of the improvement.
      
      Bug: v8:8895
      Tbr: jgruber@chromium.org
      Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch
      Change-Id: I7f13f6f0ba86edb483e088aac145cfcf9c937fef
      Reviewed-on: https://chromium-review.googlesource.com/c/1491633
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59983}
      cc5808cd
  15. 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
  16. 19 Feb, 2019 1 commit
  17. 18 Feb, 2019 1 commit
  18. 15 Feb, 2019 1 commit
  19. 13 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [builtins] Improve CallApiCallback calling convention. · c142e0a2
      Benedikt Meurer authored
      Refactor the CallApiCallback builtin to
      
      - pass the context as with other stubs, and
      - pass holder and call data in registers.
      
      This avoids having to place holder and call data onto the stack, and
      thus makes it possible to easily call the CallApiCallback builtin from
      other builtins while just forwarding the (stack) arguments. The idea
      is to use this in the future to optimize the general case of calling
      into any API method via a FunctionTemplateInfo and doing appropriate
      security and/or interface checks upfront as necessary (eventually making
      the HandleApiCall C++ builtin obsolete at some point).
      
      Bug: v8:8820, chromium:913553
      Change-Id: I10c0065016df4d0c24bac3d46945ea597b65ed02
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1469821
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59551}
      c142e0a2
  20. 12 Feb, 2019 1 commit
  21. 11 Feb, 2019 2 commits
  22. 08 Feb, 2019 1 commit
    • Gus Caplan's avatar
      Reland^2 "[builtins] [turbofan] Refactor Float64Pow to use single implementation" · 98453126
      Gus Caplan authored
      This is a reland of d7def900
      
      Original change's description:
      > Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"
      >
      > This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      >
      > Original change's description:
      > > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      > >
      > > Remove platform-specific Float64Pow implementations and utils Pow in
      > > favor of a base::ieee754::pow implementation.
      > >
      > > This unifies the implementation of pow for the compiler, wasm, and
      > > runtime.
      > >
      > > Bug: v8:5848, v8:5086
      > > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59229}
      >
      > Bug: v8:5848, v8:5086
      > Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59411}
      
      Tbr: neis@chromium.org, bmeurer@chromium.org, jkummerow@chromium.org
      Bug: v8:5848, v8:5086
      Change-Id: I42972b29b8830ed47a00b2b1d408d3005a810c0e
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1456302Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59454}
      98453126
  23. 06 Feb, 2019 2 commits
    • Sigurd Schneider's avatar
      Revert "Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"" · d691fde3
      Sigurd Schneider authored
      This reverts commit d7def900.
      
      Reason for revert: Breaks UBSan:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20UBSan/4542
      
      Besides undefined behavior, things were looking good!
      
      
      Original change's description:
      > Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"
      > 
      > This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > 
      > Original change's description:
      > > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      > >
      > > Remove platform-specific Float64Pow implementations and utils Pow in
      > > favor of a base::ieee754::pow implementation.
      > >
      > > This unifies the implementation of pow for the compiler, wasm, and
      > > runtime.
      > >
      > > Bug: v8:5848, v8:5086
      > > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59229}
      > 
      > Bug: v8:5848, v8:5086
      > Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59411}
      
      TBR=jkummerow@chromium.org,jarin@chromium.org,neis@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org,me@gus.host
      
      Change-Id: I65c4bbd3ab7aaa1c396d182467c5a1fe6a639df5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5848, v8:5086
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1456107Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59419}
      d691fde3
    • Gus Caplan's avatar
      Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation" · d7def900
      Gus Caplan authored
      This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      
      Original change's description:
      > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      >
      > Remove platform-specific Float64Pow implementations and utils Pow in
      > favor of a base::ieee754::pow implementation.
      >
      > This unifies the implementation of pow for the compiler, wasm, and
      > runtime.
      >
      > Bug: v8:5848, v8:5086
      > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59229}
      
      Bug: v8:5848, v8:5086
      Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59411}
      d7def900
  24. 05 Feb, 2019 1 commit
  25. 31 Jan, 2019 2 commits
  26. 17 Jan, 2019 1 commit
  27. 10 Jan, 2019 1 commit
    • tzik's avatar
      Shuffle the parameter ordering of JSEntry · 7efa02a3
      tzik authored
      This moves |root_register_value| parameter of JSEntryFunction to the
      first. I.e. the type of entry function will be changed from
       Object*(Object* new_target, Object* target, Object* receiver,
               int argc, Object*** args,
               Address root_register_value)
      to
       Object*(Address root_register_value,
               Object* new_target, Object* target, Object* receiver,
               int argc, Object*** args),
      and moves all parameter handling except for |root_register_value| from
      JSEntryVariant to JSEntryTrampolineHelper.
      
      This is a preparation to add another JS entry point for RunMicrotasks,
      whose type will be
       Object*(Address root_register_value, MicrotaskQueue*).
      The new entry point requires |root_register_value| to be the first to
      share the implementation of the EntryFrame setup with existing ones.
      
      Bug: v8:8124
      Change-Id: I675376a2ccd240f61cf04eea6fe9a91031e06ede
      Reviewed-on: https://chromium-review.googlesource.com/c/1372857
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58683}
      7efa02a3
  28. 08 Jan, 2019 1 commit
    • tzik's avatar
      Pass argc of JSEntry as intptr_t · 088f9c60
      tzik authored
      |argc| parameter of JSEntry is passed as int from C++ code, and loaded
      into a register on the asm code. As int is 32 bit, and registers are
      64 bit on 64 bit platforms, upper 32 bits of the loaded value may be
      contaminated by a random value if it's passed as a stack parameter.
      
      For now, |argc| is passed as a register parameter on all platforms, and
      the upper 32 bits of |argc| is filled by zero, fortunately. However, if
      we shuffle the order of parameters, |argc| can be passed as a stack
      parameter and its value may be broken.
      
      Specifically on x64 Windows, the first 4 parameters are passed as
      register parameters and the rest are stack parameters. As |argc| is the
      4th parameter, if we prepend another parameter and shift |argc| to
      the 5th parameter, |argc| will become a stack parameter and its load
      to 64 bit register breaks the value.
      
      This CL converts the type of the |argc| parameter to intptr_t, so that
      it's safe to load from stack to full width registers.
      
      Bug: v8:8124
      Change-Id: Ie7407cf5e6252ed7323a9c42389db387b0064673
      Reviewed-on: https://chromium-review.googlesource.com/c/1400326Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58614}
      088f9c60