1. 05 Mar, 2020 2 commits
  2. 28 Feb, 2020 1 commit
  3. 19 Feb, 2020 1 commit
  4. 16 Jan, 2020 1 commit
    • Jakob Gruber's avatar
      [compiler] Consider pushed arguments in stack check offset · 2cd24eba
      Jakob Gruber authored
      Function calls can push arguments onto the stack. The consumed stack
      slots are not considered by the function-entry stack check, since
      initial frame setup only reserves space for local slots, not call
      arguments. This CL adds such logic by tracking the maximum pushed
      argument count during instruction selection, and adding these slots to
      the (existing) stack check offset logic in code generation.
      
      Bug: chromium:1030167
      Change-Id: I26a9407cf38009839b1dda2ff0c8ec297c15ed8d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002540
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65814}
      2cd24eba
  5. 06 Nov, 2019 1 commit
  6. 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
  7. 28 Oct, 2019 1 commit
  8. 12 Sep, 2019 3 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
    • Georg Neis's avatar
      [compiler] Replace remaining mutable reference arguments · 2304c194
      Georg Neis authored
      Bug: v8:9429
      Change-Id: Id775a765d9700e1d2c46b4598f5e4c8350e28f14
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796340Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63705}
      2304c194
    • 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
  9. 29 Aug, 2019 1 commit
  10. 26 Aug, 2019 1 commit
  11. 23 Aug, 2019 2 commits
  12. 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
  13. 12 Aug, 2019 2 commits
    • Jakob Gruber's avatar
      [compiler] Widen optimization for external reference loads · 33e1a6e9
      Jakob Gruber authored
      Turbofan applies the following optimization to external reference
      loads on arm64 and x64: if the root-relative offset to an external
      reference's address is known to be constant (and the root register has
      been initialized), calculate the external reference as |kRootRegister
      + <offset>| instead of loading it from the external reference table.
      
      There are two main cases to consider:
      
      1. External references to arbitrary addresses in the native address
      space, e.g. libc_memcpy. These kinds of external references have a
      fixed address within the same running process, but may (and likely
      will) change between processes (e.g.: mksnapshot and later chromium),
      and the root-relative offset is different for each Isolate within the
      same process.
      
      These kinds of external references can be optimized as above when
      *not* generating code which will later be serialized, and *not*
      generating isolate-independent code.
      
      2. External references to addresses within the fixed-size region of
      the Isolate (essentially: within IsolateData). Since these move with
      the Isolate, their root-relative offset is guaranteed to be constant
      at all times.
      
      The optimization can always be applied to these cases as long as the
      root register has been initialized.
      
      Prior to this CL, we only recognized and optimized for case 1. This CL
      additionally adds support for 2.
      
      An example of improved code generated due to this CL:
      
      Before:
      // r13 is the kRootRegister on x64.
      // 0x3010 is the root-relative offset to Isolate::context_address.
      leaq rdx, [r13+0x3010]
      movq r8, [rdx]
      
      After:
      movq rdx, [r13+0x3010]
      
      Bug: v8:9534
      Change-Id: Idfcca751e98a56c0e5ead2c701c12a677df75399
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748727
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63158}
      33e1a6e9
    • Jakob Gruber's avatar
      [compiler] Refactor stack check handling · 0aa204fe
      Jakob Gruber authored
      This CL unifies how stack checks are handled in the Turbofan pipeline
      across architectures, in preparation for properly handling stack
      overflows caused by deoptimization in follow-up work. It will also
      open up possibilities to simplify related logic.
      
      How this used to work: JSStackCheck was lowered to a UintLessThan
      with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
      this node pattern was later recognized during instruction selection
      and rewritten to dedicated operators. On other platforms, including
      arm and arm64, special logic exists to avoid useless
      register-to-register moves when accessing the sp.
      
      This CL introduces a new StackPointerGreaterThan operator, which takes
      the stack limit as its sole input. This is what JSStackCheck now lowers
      to. This is threaded through to code generation, where we emit the
      appropriate code (in the future, we will apply an additional offset to
      the sp here).
      
      In follow-up CLs, we can remove or replace remaining uses of
      LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
      the LoadStackPointer operator, related node matchers, related register
      constraints, and the pseudo-smi stack limit roots.
      
      Bug: v8:9534
      Change-Id: I0e3f1beeed65b163c4ee5787600bed8c3cc671e1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738863Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63156}
      0aa204fe
  14. 07 Aug, 2019 1 commit
  15. 01 Aug, 2019 1 commit
  16. 17 Jul, 2019 1 commit
  17. 16 Jul, 2019 1 commit
  18. 08 Jul, 2019 1 commit
  19. 24 May, 2019 1 commit
  20. 21 May, 2019 1 commit
  21. 06 May, 2019 1 commit
  22. 29 Mar, 2019 2 commits
  23. 19 Dec, 2018 1 commit
  24. 12 Nov, 2018 1 commit
  25. 31 Oct, 2018 1 commit
  26. 18 Oct, 2018 1 commit
  27. 30 Jul, 2018 1 commit
  28. 06 Jul, 2018 1 commit
  29. 28 Jun, 2018 1 commit
  30. 26 Jun, 2018 1 commit
  31. 19 Jun, 2018 1 commit
  32. 13 Jun, 2018 1 commit