Skip to content

V
V8
Switch branch/tag
  1. 25 Sep, 2017 1 commit
  3. 03 Aug, 2017 1 commit
  5. 16 May, 2017 1 commit
  7. 09 May, 2017 2 commits
  9. 11 Jan, 2017 1 commit
  11. 13 Jul, 2016 1 commit
  13. 12 Jul, 2016 1 commit
  15. 11 Jul, 2016 1 commit
  17. 20 Apr, 2016 1 commit
    • mtrofin's avatar
      [turbofan] CodeGenerator: Frame setup refactoring · 81a1530e
      mtrofin authored 
      Before frame elision, we finalized the frame shape when assembling the
prologue, which is also when we prepared the frame (saving sp, etc).

The frame finalization only needs to happen once, and happens to be
actually a set of idempotent operations. With frame elision, the logic for
frame finalization was happening every time we constructed the frame.
Albeit idempotent operations, the code would become hard to maintain.

This change separates frame shape finalization from frame
construction. When constructing the CodeGenerator, we finalize the
frame. Subsequent access is to a const Frame*.

Also renamed AssemblePrologue to AssembleConstructFrame, as
suggested in the frame elision CR.

Separating frame setup gave the opportunity to do away with
architecture-independent frame aligning (which is something just arm64
cares about), and also with stack pointer setup (also arm64). Both of
these happen now at frame finalization on arm64.

BUG=

Review URL: https://codereview.chromium.org/1843143002

Cr-Commit-Position: refs/heads/master@{#35642}
      81a1530e
  19. 12 Apr, 2016 1 commit
  21. 30 Mar, 2016 1 commit
  23. 11 Mar, 2016 1 commit
  25. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored 
      Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.

This CL attempts to improve this by:

* Ensuring that there are only two fundamentally different
  types of frames, a "standard" frame and a "typed" frame.
  Standard frames, as before, contain both a context and
  function pointer. Typed frames contain only a minimum
  of a smi marker in the position immediately below the fp
  where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
  TurboFan JavaScript frames use the "standard" format. All
  other frames use the type frame format with an explicit
  marker.
* Typed frames can contain one or more values below the
  type marker. There is new magic macro machinery in
  frames.h that simplifies defining the offsets of these fields
  in typed frames.
* A new flag in the CallDescriptor enables specifying whether
  a frame is a standard frame or a typed frame. Secondary
  register location spilling is now only enabled for standard
  frames.
* A zillion places in the code have been updated to deal with
  the fact that most code stubs and internal frames use the
  typed frame format. This includes changes in the
  deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
  (CommonFrameConstants::kContextOrFrameTypeOffset
  and StandardFrameConstants::kFrameOffset are now used
  in its stead).

LOG=N

Review URL: https://codereview.chromium.org/1696043002

Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  27. 18 Feb, 2016 1 commit
  29. 17 Feb, 2016 2 commits
  31. 11 Jan, 2016 1 commit
  33. 05 Jan, 2016 1 commit
  35. 24 Nov, 2015 1 commit
    • danno's avatar
      [turbofan] Add general support for sp-based frame access · 51669873
      danno authored 
      Some highlights of this CL:
* Refactor the mutable state out of Frame into FrameAccessState,
  which is maintained and updated during code generation to
  record whether sp- or fp-based frame access is currently active
  and how deep the stack on top of the frame is.
* The operand resultion in linkage.cc now uses FrameAccessState
  to determine how to generate frame-accessing operands.
* Update all platforms to accurately track additionally pushed
  stack slots (e.g. arguments for calls) in the FrameAccessState.
* Add a flag, --turbo_sp_frame_access, which forces all frame
  access to be sp-based whenever possible. This will likely never
  be used in production, but for testing it's useful in verifying
  that the stack-tracking of each platform maintained in the
  FrameAccessState is correct.
* Use sp-based frame access for gap resolving before tail
  calls. This will allow for slightly more efficient restoration
  of the frame pointer in the tail call in a later CL.
* Remove most ad hoc groping into CallDescriptors to
  determine if a frame is needed, instead consistently use
  predicates like needs_frame(), IsCFunctionCall() and
  IsJSFunctionCall().

BUG=v8:4076
LOG=n

Review URL: https://codereview.chromium.org/1460183002

Cr-Commit-Position: refs/heads/master@{#32234}
      51669873
  37. 19 Nov, 2015 1 commit
    • jacob.bramley's avatar
      [arm64] Use SP-offset rather than FP-offset. · dad635ee
      jacob.bramley authored 
      A64 loads and stores can have much larger positive than negative
immediate offsets, and since most frame slots are below fp, we can
significantly improve accesses by basing them on sp instead. Typical
example:

    Before                  After
    mov x16, #-416
    str x20, [fp, x16]      str x20, [jssp, #32]

Notable benchmark results include lua_binarytrees, which improves by
about 7.5% on A57 and 5% on A53. Several other asm.js benchmarks gain
2-4%.

Review URL: https://codereview.chromium.org/1376173003

Cr-Commit-Position: refs/heads/master@{#32111}
      dad635ee
  39. 13 Nov, 2015 2 commits
    • mbrandy's avatar
      Fix "[turbofan] Spill rsi and rdi in their existing locations." · 61a39335
      mbrandy authored 
      Commit 20f3a077 broke platforms using
embedded constant pools due to assumptions regarding stack frame
layout.

R=mtrofin@chromium.org, bmeurer@chromium.org, jarin@chromium.org, michael_dawson@ca.ibm.com
BUG=v8:4548
LOG=n

Review URL: https://codereview.chromium.org/1442273002

Cr-Commit-Position: refs/heads/master@{#31996}
      61a39335
    • mtrofin's avatar
      [turbofan] Spill rsi and rdi in their existing locations. · 20f3a077
      mtrofin authored 
      We push the context and the js function onto the stack as part of the
frame construction. The register allocator is presented with virtual
registers for the above as defined from their corresponding registers. It
then goes on to spilling them somewhere else on the stack.

This means each function spends two redundant spills and two
unnecessary stack slots.

This change addresses this issue.

We present these parameters (context and function) to the register
allocator as an UnallocatedOperand having a "secondary storage". The
secondary storage is then associated to the live range as its
spill operand. We capture the definition of the live range so that we can
then commit the spill (in this case, eliminate) through a variation of the
mechanics of the CommitAssignment phase.

The register allocator validator also needed update to understand
UnallocatedOperands with a secondary storage.

The change renames the SpillAtDefinitionList and related APIs to better
capture their intent - the old names suggested spills happened upon
calling. In reality, potential spill locations were thus recorded, and later
committed (or not, in certain cases) after register allocation.

BUG= v8:4548
LOG=n

Review URL: https://codereview.chromium.org/1426943010

Cr-Commit-Position: refs/heads/master@{#31988}
      20f3a077
  41. 30 Sep, 2015 1 commit
  43. 29 Sep, 2015 1 commit
    • jacob.bramley's avatar
      Fix Frame::AlignSavedCalleeRegisterSlots · 0a844bc0
      jacob.bramley authored 
      The return value is expected to be the number of padding slots added to the frame. However, the original logic would return -1 if padding was required, so insufficient stack space would be reserved.

This function now returns either 0 or 1, as the existing calling code expects.

BUG=

Review URL: https://codereview.chromium.org/1369303002

Cr-Commit-Position: refs/heads/master@{#30994}
      0a844bc0
  45. 18 Aug, 2015 1 commit
    • danno's avatar
      [turbofan] Unify referencing of stack slots · cbbaf9ea
      danno authored 
      Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.

In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.

The following changes were specifically	needed:

* Frame	has been changed to explicitly manage three areas of the
  callee frame, the fixed header, the spill slot area, and the
  callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
  a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
  to support the new stack slot indexing scheme. Crankshaft, which
  doesn't support the new slot numbering in its register allocator,
  must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
  to support saving only the optimal set of used registers, which is
  only known after register allocation is finished and spill slots
  have been allocated.

Review URL: https://codereview.chromium.org/1261923007

Cr-Commit-Position: refs/heads/master@{#30224}
      cbbaf9ea
  47. 11 Aug, 2015 2 commits
  49. 10 Aug, 2015 1 commit
  51. 29 Apr, 2015 3 commits
  53. 09 Feb, 2015 1 commit
  55. 02 Feb, 2015 1 commit
  57. 12 Jan, 2015 1 commit
  59. 14 Nov, 2014 1 commit
  61. 31 Oct, 2014 1 commit
  63. 04 Aug, 2014 1 commit
  65. 30 Jul, 2014 1 commit