1. 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
  2. 12 Apr, 2016 1 commit
  3. 30 Mar, 2016 1 commit
  4. 11 Mar, 2016 1 commit
  5. 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
  6. 11 Jan, 2016 1 commit
  7. 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
  8. 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
  9. 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