1. 13 Sep, 2019 3 commits
  2. 12 Sep, 2019 8 commits
  3. 11 Sep, 2019 2 commits
  4. 10 Sep, 2019 3 commits
  5. 09 Sep, 2019 2 commits
  6. 05 Sep, 2019 1 commit
  7. 04 Sep, 2019 1 commit
  8. 03 Sep, 2019 4 commits
  9. 02 Sep, 2019 2 commits
  10. 29 Aug, 2019 2 commits
  11. 26 Aug, 2019 1 commit
  12. 23 Aug, 2019 5 commits
  13. 22 Aug, 2019 5 commits
    • 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
    • Ng Zhi An's avatar
      [wasm-simd] Implement F64x2 min max for arm64 · 573e0cce
      Ng Zhi An authored
      Bug: v8:8460
      Change-Id: I16df8eee6146704e26c6e784452ad8dc4621a460
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1749711Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63354}
      573e0cce
    • Bill Budge's avatar
      Revert "[compiler] Track the maximal unoptimized frame size" · 98b5c49f
      Bill Budge authored
      This reverts commit 1e472c42.
      
      Reason for revert: Speculative revert, to attempt to fix crashes that block the V8 roll. Example failure run:
      
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/173465
      
      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}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: I7b225c30bfc4e1d958276583f512a1ec5fa2b458
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764626Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63350}
      98b5c49f
    • Joey Gouly's avatar
      [arm64] Allow immediate operands to be swapped in compares · e0a2d93e
      Joey Gouly authored
      This was deleted in 5b2ab2f6, it seems only
      the first part of the condition should have been deleted.
      
      This changes (from the embedded builtins):
      
          movz x9, #0x2
          cmp x9, x8
      
      Back to:
      
          cmp x8, #0x2
      
      This saves 0.29% in the embedded builtins size for a pointer-compression enabled arm64 build.
      
      Also a minor cleanup by removing the commutative boolean parameter and always commuting the
      FlagsContinuation. For a commutative operation the FlagsContinuation will stay the same.
      
      Change-Id: I5bba84a07bb32284b4756bc6293560ee106745f2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762522Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
      Cr-Commit-Position: refs/heads/master@{#63337}
      e0a2d93e
    • Jakob Gruber's avatar
      [compiler] Track the maximal unoptimized frame size · 1e472c42
      Jakob Gruber authored
      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: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63330}
      1e472c42
  14. 21 Aug, 2019 1 commit