R=bmeurer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33202}

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}

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}

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}