This makes the aforementioned visitation function independent of the
target architecture by leveraging existing abstractions.

R=ishell@chromium.org

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

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

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

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

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

Upstream S390 platform specific code to latest lkgr from the past 2 weeks.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

Port 21b331e3

BUG=

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

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

FullCodegen generates 2 statement positions for the loop init block, like so:

  for(var i = 0; i....
      ^   ^

This change removes the first of those, updates unit tests,
and removes text expectations for Ignition.

---
An alternative would be to emulate the existing behaviour in Ignition, but:
- The new behaviour seems more logical,
- Ignition generates no bytecodes for the 'var', meaning there is no code position to attach the break position to.

BUG=v8:4690
LOG=Y

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

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

R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org
BUG=v8:3956
LOG=Y

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

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

Port 9dcd0857

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=

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

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

This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

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

TBR=machenbach@chromium.org
NOTRY=true
NOTREECHECKS=true

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

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

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

Committed: https://crrev.com/4a7722c9930a42ba0e8feeece286d74834211a7e
Cr-Commit-Position: refs/heads/master@{#34569}

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

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

R=yangguo@chromium.org

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

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

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}

Revert of [interpreter, debugger] add some missing statement positions. (patchset #1 id:1 of https://codereview.chromium.org/1770773002/ )

Reason for revert:
failing tests with ignition.

Original issue's description:
> [interpreter, debugger] add some missing statement positions.
>
> R=rmcilroy@chromium.org, vogelheim@chromium.org
> BUG=v8:4690
> LOG=N
>
> Committed: https://crrev.com/4a7722c9930a42ba0e8feeece286d74834211a7e
> Cr-Commit-Position: refs/heads/master@{#34569}

TBR=rmcilroy@chromium.org,vogelheim@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4690

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

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

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

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

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

Now there is just one kind, corresponding to what was called "initial" before.
Replacement for "suspend": when the parser sees a yield in JS code, it
will turn it into a Yield node but wrap its argument in an iterator result
object.  Replacement for "final": the parser simply inserts a return statement
instead.

R=littledan@chromium.org, mstarzinger@chromium.org
BUG=

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

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

R=mvstanton@chromium.org

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

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

This is more consistent with the current naming scheme (i.e. IsCallable
for callable bit on map, IsConstructor for constructor bit on map, and
now IsUndetectable for undetectable bit on map).

Also simplify the fallthrough case for Object::Equals, because we don't
need to check for Null or Undefined or Undetectable, as both Null and
Undefined already have the undetectable bit set on their maps.

R=machenbach@chromium.org

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

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

The function literal consists of a list of statements. Each statement
is associated with a statement position including break location. The
only exception to this rule is when the function immediately throws if
scope resolution found an illegal redeclaration. Make sure that we add a
break location for this case as well. The debugger relies on this.

R=bmeurer@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

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

We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.

With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.

Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
  position of the return statement.
- right before the actual return, there is another break location. The
  source position points to the end of the function.

R=rmcilroy@chromium.org, vogelheim@chromium.org
TBR=rossberg@chromium.org
BUG=v8:4690
LOG=N

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

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

The only place in fullcodegen, where we know for sure that a for-in loop
entered the slow-path is right before the potential call to %ForInFilter.
So there's no point in also updating the mode eagerly during ForInPrepare.

R=yangguo@chromium.org
BUG=v8:3650
LOG=n

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

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

Port fb59ea33

Original commit message:
    Since both null and undefined are also marked as undetectable now, we
    can just test that bit instead of having the CompareNilIC try to collect
    feedback to speed up the general case (without the undetectable bit
    being used).

    Drive-by-fix: Update the type system to match the new handling of
    undetectable in the runtime.

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

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

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

Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

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

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

Since both null and undefined are also marked as undetectable now, we
can just test that bit instead of having the CompareNilIC try to collect
feedback to speed up the general case (without the undetectable bit
being used).

Drive-by-fix: Update the type system to match the new handling of
undetectable in the runtime.

R=danno@chromium.org

Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba
Cr-Commit-Position: refs/heads/master@{#34237}

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

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

Revert of PPC: [compiler] Drop the CompareNilIC. (patchset #1 id:1 of https://codereview.chromium.org/1733663003/ )

Reason for revert:
Original commit reverted.

Original issue's description:
> PPC: [compiler] Drop the CompareNilIC.
>
> Port 666aec03
>
> Original commit message:
>     Since both null and undefined are also marked as undetectable now, we
>     can just test that bit instead of having the CompareNilIC try to collect
>     feedback to speed up the general case (without the undetectable bit
>     being used).
>
>     Drive-by-fix: Update the type system to match the new handling of
>     undetectable in the runtime.
>
> R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/546ea6b8393a894f07597ade5ec1c7db02c1e425
> Cr-Commit-Position: refs/heads/master@{#34266}

TBR=bmeurer@chromium.org,joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

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

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

Port 3ef573e9

Original commit message:

    Replace the somewhat awkward RestParamAccessStub, which would always
    call into the runtime anyway with a proper FastNewRestParameterStub,
    which is basically based on the code that was already there for strict
    arguments object materialization. But for rest parameters we could
    optimize even further (leading to 8-10x improvements for functions with
    rest parameters), by fixing the internal formal parameter count:

    Every SharedFunctionInfo has a formal_parameter_count field, which
    specifies the number of formal parameters, and is used to decide whether
    we need to create an arguments adaptor frame when calling a function
    (i.e. if there's a mismatch between the actual and expected parameters).
    Previously the formal_parameter_count included the rest parameter, which
    was sort of unfortunate, as that meant that calling a function with only
    the non-rest parameters still required an arguments adaptor (plus some
    other oddities). Now with this CL we fix, so that we do no longer
    include the rest parameter in that count. Thereby checking for rest
    parameters is very efficient, as we only need to check whether there is
    an arguments adaptor frame, and if not create an empty array, otherwise
    check whether the arguments adaptor frame has more parameters than
    specified by the formal_parameter_count.

    The FastNewRestParameterStub is written in a way that it can be directly
    used by Ignition as well, and with some tweaks to the TurboFan backends
    and the CodeStubAssembler, we should be able to rewrite it as
    TurboFanCodeStub in the near future.

    Drive-by-fix: Refactor and unify the CreateArgumentsType which was
    different in TurboFan and Ignition; now we have a single enum class
    which is used in both TurboFan and Ignition.

TEST=test/mjsunit/harmony/destructuring, test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters, test/mjsunit/es6/classes-subclass-builtins,
BUG=

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

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

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

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

Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.

The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.

Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.

Still to do is tracking source positions which will be done in a
followup CL.

BUG=v8:4766
LOG=N

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

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

Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of https://codereview.chromium.org/1722193002/ )

Reason for revert:
Speculative revert in attempt to fix #2 crasher on canary.

Original issue's description:
> [compiler] Drop the CompareNilIC.
>
> Since both null and undefined are also marked as undetectable now, we
> can just test that bit instead of having the CompareNilIC try to collect
> feedback to speed up the general case (without the undetectable bit
> being used).
>
> Drive-by-fix: Update the type system to match the new handling of
> undetectable in the runtime.
>
> R=danno@chromium.org
>
> Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba
> Cr-Commit-Position: refs/heads/master@{#34237}

TBR=danno@chromium.org,verwaest@chromium.org,bmeurer@chromium.org
LOG=y
BUG=chromium:589897
NOTRY=true

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

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

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

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

  port ee8108b7 (r34246)

  original commit message:
  This implements proper handling of local control flow (i.e. break and
  continue) that spans the boundary of a do-expression. We can no longer
  determine the number of operands to be dropped from the nesting of
  statements alone, instead we use the new precise operand stack depth
  tracking.

BUG=

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

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

  port 666aec03 (r34237)

  original commit message:
  Since both null and undefined are also marked as undetectable now, we
  can just test that bit instead of having the CompareNilIC try to collect
  feedback to speed up the general case (without the undetectable bit
  being used).

  Drive-by-fix: Update the type system to match the new handling of
  undetectable in the runtime.

BUG=

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

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

Port 666aec03

Original commit message:
    Since both null and undefined are also marked as undetectable now, we
    can just test that bit instead of having the CompareNilIC try to collect
    feedback to speed up the general case (without the undetectable bit
    being used).

    Drive-by-fix: Update the type system to match the new handling of
    undetectable in the runtime.

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

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

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

Port ee8108b7

Original commit message:
    This implements proper handling of local control flow (i.e. break and
    continue) that spans the boundary of a do-expression. We can no longer
    determine the number of operands to be dropped from the nesting of
    statements alone, instead we use the new precise operand stack depth
    tracking.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
TEST=mjsunit/harmony/do-expressions-control
BUG=v8:4488
LOG=n

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

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

This makes the aforementioned emitting function independent of the
target architecture by leveraging existing abstractions.

R=mvstanton@chromium.org

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

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

This makes the FullCodeGenerator::EmitNamedPropertyLoad be architecture
independent by adding MacroAssembler::Move helpers.

R=bmeurer@chromium.org

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

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

This fixes a corner case that triggered an assert in full-codegens
operand stack depth tracking. We stop pushing operands if we overflow
the C-stack while iterating the AST. This makes the tracking go out of
sync before we fully returned from the tree traversal, at which point
the thrown RangeError will abort compilation.

R=ishell@chromium.org
TEST=mjsunit/regress/regress-crbug-589472
BUG=chromium:589472
LOG=n

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

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

This implements proper handling of local control flow (i.e. break and
continue) that spans the boundary of a do-expression. We can no longer
determine the number of operands to be dropped from the nesting of
statements alone, instead we use the new precise operand stack depth
tracking.

R=jarin@chromium.org
TEST=mjsunit/harmony/do-expressions-control
BUG=v8:4488
LOG=n

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

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

Since both null and undefined are also marked as undetectable now, we
can just test that bit instead of having the CompareNilIC try to collect
feedback to speed up the general case (without the undetectable bit
being used).

Drive-by-fix: Update the type system to match the new handling of
undetectable in the runtime.

R=danno@chromium.org

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

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