1. 30 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Optionally apply an offset to stack checks" · b875f466
      Jakob Gruber authored
      This is a reland of 4a16305b
      
      The original CL adjust only one part of the stack check, namely the
      comparison of the stack pointer against the stack limit in generated code.
      There is a second part: Runtime::kStackGuard repeats this check to
      distinguish between a stack overflow and an interrupt request.
      
      This second part in runtime must apply the offset just like in generated
      code. It is implemented in this reland by the StackCheckOffset operator
      and a new StackGuardWithGap runtime function.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      >
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      >
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      >
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      >
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      >
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      Bug: v8:9534, chromium:1000887
      Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64634}
      b875f466
  2. 25 Oct, 2019 1 commit
  3. 16 Oct, 2019 1 commit
  4. 11 Oct, 2019 1 commit
  5. 30 Sep, 2019 2 commits
  6. 27 Sep, 2019 4 commits
    • Peter Marshall's avatar
      [cpu-profiler] Fix stack iterability during deopt (arm port) · 559a0034
      Peter Marshall authored
      We didn't think this affected arm but it turns out it does.
      
      This is a port of
      https://chromium-review.googlesource.com/c/v8/v8/+/1688049
      
      Bug: v8:9057
      Change-Id: I671737107e589673fc32c5fa1760d887d1bcc240
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826665Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64024}
      559a0034
    • Mythri A's avatar
      Reland "[compiler] Cache OSR optimized code" · fcff2437
      Mythri A authored
      This is a reland of cfb10028
      with a fix for failures in lite mode.
      
      Original change's description:
      > [compiler] Cache OSR optimized code
      >
      > With lazy feedback allocation, for functions that get OSRed we may
      > not have feedback for the initial part of the functions since feedback
      > vectors might be allocated after the function started executing. Hence
      > we would not be able to optimize the function on the next call. This
      > means we may have to OSR twice before we actually optimize function.
      > This cl introduces OSR cache, so we could reuse the optimized code. One
      > side effect of this cl is that the OSRed code won't be function context
      > specialized anymore.
      >
      > Bug: chromium:987523
      > Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64014}
      
      Bug: chromium:987523
      Change-Id: I9c782242b07b24d15247533ab4ee044334b429ff
      TBR: rmcilroy@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826898
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64023}
      fcff2437
    • Michael Achenbach's avatar
      Revert "[compiler] Cache OSR optimized code" · f8a08223
      Michael Achenbach authored
      This reverts commit cfb10028.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/6483
      
      Original change's description:
      > [compiler] Cache OSR optimized code
      > 
      > With lazy feedback allocation, for functions that get OSRed we may
      > not have feedback for the initial part of the functions since feedback
      > vectors might be allocated after the function started executing. Hence
      > we would not be able to optimize the function on the next call. This
      > means we may have to OSR twice before we actually optimize function.
      > This cl introduces OSR cache, so we could reuse the optimized code. One
      > side effect of this cl is that the OSRed code won't be function context
      > specialized anymore.
      > 
      > Bug: chromium:987523
      > Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64014}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org
      
      Change-Id: Ib3692e7570bed5d3e88ca8a0247b185d70497a04
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:987523
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826668Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64015}
      f8a08223
    • Mythri A's avatar
      [compiler] Cache OSR optimized code · cfb10028
      Mythri A authored
      With lazy feedback allocation, for functions that get OSRed we may
      not have feedback for the initial part of the functions since feedback
      vectors might be allocated after the function started executing. Hence
      we would not be able to optimize the function on the next call. This
      means we may have to OSR twice before we actually optimize function.
      This cl introduces OSR cache, so we could reuse the optimized code. One
      side effect of this cl is that the OSRed code won't be function context
      specialized anymore.
      
      Bug: chromium:987523
      Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64014}
      cfb10028
  7. 19 Sep, 2019 1 commit
    • Jakob Gruber's avatar
      [build] Define V8_TARGET_OS_ and consider it in x64 codegen · 99d31b43
      Jakob Gruber authored
      This CL allows us to distinguish between the host- and target OS. The
      host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is
      defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN).
      
      V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn
      variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS
      (this determines fall-back behavior in V8; if it is not defined, we set
      V8_TARGET_OS_ to equal the equivalent V8_OS_ define).
      
      Besides adding the defines, this CL also adds logic to consider the
      target OS in codegen. Specifically, x64 builds now look at the
      V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This
      effectively makes cross-compilation to x64 Windows in mksnapshot
      possible.
      
      In future work, we could add similar support for cross-compiling to
      other platforms such as ia32 Windows.
      
      Bug: v8:9736,chromium:803591
      Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63892}
      99d31b43
  8. 16 Sep, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Fix and simplify optimization of access on global proxy · 97c89ebb
      Georg Neis authored
      We used to have two special cases for named accesses on the global
      proxy, one based on seeing the global proxy constant in the graph and
      on based on seeing the global proxy map either in the feedback or in
      the graph. A change I made a while ago accidentally disabled the second
      one. This CL restores that.
      
      Moreover, given how things are set up now (this might have been
      different before), the first optimization is subsumed by the second
      one, so this CL also removes the first one.
      
      Finally, this CL records an accumulator hint in the case of a load,
      which improves precision of the serializer for concurrent inlining.
      
      Tbr: tebbi@chromium.org
      Bug: v8:7790
      Change-Id: I255afc6c79e5c5c900b3ccfcd8459d836d21e42b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801954
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63806}
      97c89ebb
  9. 13 Sep, 2019 1 commit
  10. 12 Sep, 2019 2 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Optionally apply an offset to stack checks" · ba72dc08
      Jakob Gruber authored
      This reverts commit 4a16305b.
      
      Reason for revert: Need to revalidate assumptions behind the CHECK.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      > 
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      > 
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      > 
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      > 
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      > 
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534, chromium:1000887
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63706}
      ba72dc08
    • Jakob Gruber's avatar
      [compiler] Optionally apply an offset to stack checks · 4a16305b
      Jakob Gruber authored
      The motivation behind this change is that the frame size of an optimized
      function and its unoptimized version may differ, and deoptimization
      may thus trigger a stack overflow. The solution implemented in this CL
      is to optionally apply an offset to the stack check s.t. the check
      becomes 'sp - offset > limit'. The offset is applied to stack checks at
      function-entry, and is set to the difference between the optimized and
      unoptimized frame size.
      
      A caveat: OSR may not be fully handled by this fix since we've already
      passed the function-entry stack check. A possible solution would be to
      *not* skip creation of function-entry stack checks for inlinees.
      
      This CL: 1. annotates stack check nodes with the stack check kind, where
      kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      allocates a temporary register to store the result of the 'sp - offset'
      in instruction selection (and switches input registers to 'unique'
      mode). 3. Applies the offset in code generation.
      
      Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      
      Bug: v8:9534,chromium:1000887
      Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63701}
      4a16305b
  11. 09 Sep, 2019 1 commit
  12. 03 Sep, 2019 1 commit
    • Dominik Inführ's avatar
      Revert "[heap] Remove size from invalidated slots" · d4e168a3
      Dominik Inführ authored
      This reverts commit 93063ade.
      
      Reason for revert: Clusterfuzz found issue.
      
      Original change's description:
      > [heap] Remove size from invalidated slots
      > 
      > Slots are always valid inside an invalidated area when outside the
      > respective object's current size. This allows us to remove the size
      > from the InvalidatedSlots data structure.
      > 
      > This change was enabled by https://crrev.com/c/1771793.
      > 
      > Bug: v8:9454
      > Change-Id: I2b5a7234d47227cb6ad8d67de20e9b5a2028ae83
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773242
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63510}
      
      TBR=ulan@chromium.org,sigurds@chromium.org,tebbi@chromium.org,dinfuehr@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9454
      Change-Id: I7daf96cf50aaedd4dbdab48fd550182df94e54bf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783106Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63535}
      d4e168a3
  13. 02 Sep, 2019 1 commit
  14. 22 Aug, 2019 3 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
    • 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
    • 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
  15. 20 Aug, 2019 2 commits
  16. 19 Aug, 2019 2 commits
    • Jakob Gruber's avatar
      [deoptimizer] Refactor to clarify const variables in frame computation · d43de6c0
      Jakob Gruber authored
      DoComputeInterpretedFrame and friends are long and complex functions.
      It is often not clear which variables are constants and which are
      later modified. This CL tries to clarify, mostly by marking variables
      const when possible.
      
      Bug: v8:9534
      Change-Id: Ifa73402c392ad244ab5ea37262293f8d9db98be0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752848
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63245}
      d43de6c0
    • Jakob Gruber's avatar
      [deoptimizer] More consistent semantics of height for all frame types · 9fe6b543
      Jakob Gruber authored
      Information required for deoptimization is passed from codegen to the
      deoptimizer through so-called translations. Translations contain,
      among many other things, a 'height' field. It is used during deopts to
      calculate the unoptimized frame height (but note that it does not
      correspond exactly to the frame height itself - further calculations
      on the deopt side are needed to get to the real frame height).
      
      The height field has roughly the following data flow:
      
      1. During codegen, we serialize whatever
      FrameStateDescriptor::GetHeight() returns.
      2. During deopts, serialized translations are converted into
      TranslatedFrame objects in TranslatedState::CreateNextTranslatedFrame.
      3. These are later used to arrive at the real frame height in multiple
      spots, e.g. in DoComputeInterpretedFrame and friends.
      
      Prior to this CL, we were adding and subtracting 1 in basically random
      spots. For example, for interpreted and construct stub frames we added
      1 in step 1 and subtracted 1 in step 3. For continuation frames, we
      added 1 in step 2 and subtracted it in step 3. Argument adaptor frames
      were left untouched.
      
      This CL removes all these +-1's. The height field now contains
      locals_count() for interpreted frames, and parameters_count() for
      everything else. I also tried to make the meaning of adds/subs clearer
      through use of named constants like kTheReceiver.
      
      Bug: v8:9534
      Change-Id: I6fd26886ff5aa63930f413d879d5480578d9dc7e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751724Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63238}
      9fe6b543
  17. 13 Aug, 2019 1 commit
  18. 02 Aug, 2019 1 commit
  19. 31 Jul, 2019 2 commits
  20. 30 Jul, 2019 1 commit
    • Georgia Kouveli's avatar
      [arm64] Reduce code size of deoptimization exits · 207d6b35
      Georgia Kouveli authored
      Do not pass the deoptimization index in a register, instead infer it
      from the address we made the deoptimization call from. This makes the
      deoptimization exit sequence one instruction long instead of two.
      
      This requires emitting all deoptimization exits at the end of the
      function in a contiguous block, making sure no constant or veneer
      pools are emitted in between. This means that soft deoptimizations
      require an additional branch to the end of the function, which
      counteracts the removal of the move instruction, however soft
      deoptimizations are rare compared to eager and lazy ones.
      
      This reduces the code size of optimised functions for benchmarks like
      Octane and ARES-6 by about 4%.
      
      Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62991}
      207d6b35
  21. 29 Jul, 2019 1 commit
  22. 17 Jul, 2019 1 commit
  23. 16 Jul, 2019 1 commit
  24. 12 Jul, 2019 1 commit
  25. 11 Jul, 2019 2 commits
  26. 08 Jul, 2019 4 commits