PPC: [runtime] Unify and simplify how frames are marked

PPC: [runtime] Unify and simplify how frames are marked

Port 9dcd0857d64a117801bf91cb6caf7d6578809cb1

Original commit message:
    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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Committed: https://crrev.com/4445c095d26bfc67eb4a9353477a059db7cc1ca2
Cr-Commit-Position: refs/heads/master@{#34643}

[MTBrandyberry, 2016-03-08 23:34:28]

PTAL

[MTBrandyberry, 2016-03-08 23:34:39]

The CQ bit was checked by mbrandy@us.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2016-03-08 23:34:49]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1778713002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1778713002/1

[commit-bot: I haz the power, 2016-03-08 23:54:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-08 23:54:40]

Dry run: This issue passed the CQ dry run.

[JoranSiu, 2016-03-09 23:04:15]

On 2016/03/08 23:54:40, commit-bot: I haz the power wrote:
> Dry run: This issue passed the CQ dry run.

lgtm

[MTBrandyberry, 2016-03-09 23:04:53]

The CQ bit was checked by mbrandy@us.ibm.com

[commit-bot: I haz the power, 2016-03-09 23:04:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1778713002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1778713002/1

[commit-bot: I haz the power, 2016-03-09 23:07:19]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-09 23:08:30]

Description was changed from

==========
PPC: [runtime] Unify and simplify how frames are marked

Port 9dcd0857d64a117801bf91cb6caf7d6578809cb1

Original commit message:
    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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
BUG=
==========

to

==========
PPC: [runtime] Unify and simplify how frames are marked

Port 9dcd0857d64a117801bf91cb6caf7d6578809cb1

Original commit message:
    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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
BUG=

Committed: https://crrev.com/4445c095d26bfc67eb4a9353477a059db7cc1ca2
Cr-Commit-Position: refs/heads/master@{#34643}
==========

[commit-bot: I haz the power, 2016-03-09 23:08:31]

Patchset 1 (id:??) landed as
https://crrev.com/4445c095d26bfc67eb4a9353477a059db7cc1ca2
Cr-Commit-Position: refs/heads/master@{#34643}