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}

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}

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}

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}

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}

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}

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 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}

This implements a mechanism to track the exact depth of the operand
stack in full-codegen for every sub-expression visitation. So far we
only tracked the depth at statement level, but not at expression level.
With the introduction of do-expressions it will be possible to construct
local control flow (i.e. break, continue and friends) that target labels
at an arbitrary operand stack depth, making this tracking a prerequisite
for full do-expression support.

R=rossberg@chromium.org,jarin@chromium.org
BUG=v8:4755,v8:4488
LOG=n

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

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

This removes a restriction from full-codegen that limited the usability
of the --debug-code flag to only no-snap configurations. The reasoning
for the restriction would still hold, if we ever put full-codegen code
into the snapshot, which we don't. Also there already are several places
in full-codegen that queried the FLAG_debug_code directly, a more
reliable mechanism will be needed if we snapshot full code.

R=yangguo@chromium.org

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

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

This intrinsic was only supported in fullcodegen, and is actually no
longer relevant for SunSpider peak performance it seems, so let's get
rid of it and maybe just implement Array.prototype.join with a fast
path at some point instead.

R=mstarzinger@chromium.org

Committed: https://crrev.com/ccf12b4bede3f1ce3ce14fb33bcc4041525a40af
Cr-Commit-Position: refs/heads/master@{#34084}

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

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

This CL also enhances a "tail-call-megatest" which now tests product of the following cases:
1) tail caller is inlined/not-inlined
2) tail callee is inlined/not-inlined
3) tail caller has an arguments adaptor frame above or not
4) tail callee has an arguments adaptor frame above or not
5) tail callee is a sloppy/strict/possibly eval/bound/proxy function
6) tail calling via normal call/function.apply/function.call

BUG=v8:4698
LOG=N

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

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

Revert of [fullcodegen] Remove the hacky %_FastOneByteArrayJoin intrinsic. (patchset #1 id:1 of https://codereview.chromium.org/1708523002/ )

Reason for revert:
[Sheriff] Speculative revert for adding arm flakes:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm%20-%20sim/builds/5756
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm%20-%20sim%20-%20novfp3/builds/3375/

And some more...

Original issue's description:
> [fullcodegen] Remove the hacky %_FastOneByteArrayJoin intrinsic.
>
> This intrinsic was only supported in fullcodegen, and is actually no
> longer relevant for SunSpider peak performance it seems, so let's get
> rid of it and maybe just implement Array.prototype.join with a fast
> path at some point instead.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/ccf12b4bede3f1ce3ce14fb33bcc4041525a40af
> Cr-Commit-Position: refs/heads/master@{#34084}

TBR=mstarzinger@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

This intrinsic was only supported in fullcodegen, and is actually no
longer relevant for SunSpider peak performance it seems, so let's get
rid of it and maybe just implement Array.prototype.join with a fast
path at some point instead.

R=mstarzinger@chromium.org

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

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

There's no need to have inline platform code for this intrinsic, which
is only used when generating a descriptive string for an error, the
runtime call is just fine here.

R=jarin@chromium.org

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

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

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

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

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

It's fine to only have the runtime call here, as it's only used in the
debug mirror.

R=jarin@chromium.org

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

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

Drive-by-fix: Remove the (now) unused %_SetValueOf and %_JSValueGetValue
intrinsics from the various compilers and the runtime.

R=jarin@chromium.org

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

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

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

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

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

Turn the fast case of ArgumentsAccessStub into a new stub
FastNewSloppyArgumentsStub, which is similar to the existing
FastNewStrictArgumentsStub, although not polished yet, and the slow
case always went to the runtime anyway, so we can just directly emit
a runtime call there.

R=mstarzinger@chromium.org

Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04
Cr-Commit-Position: refs/heads/master@{#33973}

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

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

Revert of [runtime] Turn ArgumentAccessStub into FastNewSloppyArgumentsStub. (patchset #2 id:20001 of https://codereview.chromium.org/1695633003/ )

Reason for revert:
[Sheriff] Breaks ASAN with mipsel compile:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20ASAN%20mipsel%20-%20debug%20builder/builds/4558/

Original issue's description:
> [runtime] Turn ArgumentAccessStub into FastNewSloppyArgumentsStub.
>
> Turn the fast case of ArgumentsAccessStub into a new stub
> FastNewSloppyArgumentsStub, which is similar to the existing
> FastNewStrictArgumentsStub, although not polished yet, and the slow
> case always went to the runtime anyway, so we can just directly emit
> a runtime call there.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04
> Cr-Commit-Position: refs/heads/master@{#33973}

TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

Turn the fast case of ArgumentsAccessStub into a new stub
FastNewSloppyArgumentsStub, which is similar to the existing
FastNewStrictArgumentsStub, although not polished yet, and the slow
case always went to the runtime anyway, so we can just directly emit
a runtime call there.

R=mstarzinger@chromium.org

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

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

There are only two uses of %_ObjectEquals left, which should actually
use strict equality instead, so there's no need to keep this special
logic at all.

R=mvstanton@chromium.org

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

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

This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.

R=jarin@chromium.org

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

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

The FastNewStrictArgumentsStub is very similar to the recently added
FastNewRestParameterStub, it's actually almost a copy of it, except that
it doesn't have the fast case we have for the empty rest parameter. This
patch improves strict arguments in TurboFan and fullcodegen by up to 10x
compared to the previous version.

Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
for the in-object properties instead of having them as constants in the
Heap class.

Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
interpreter to avoid the runtime call overhead for strict arguments
and rest parameter creation.

R=jarin@chromium.org
TBR=mstarzinger@chromium.org

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

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

1) Update profiling counters in Full codegen.
2) Call Runtime::kTraceTailCall when tracing is on

test/mjsunit/es6/tail-call-simple.js is disabled for now, because Turbofan does not fully support TCO yet.

BUG=v8:4698
LOG=N

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

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

Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof,
%LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and
%StoreLookupSlot_Strict runtime entry points and use them
appropriately in the various compilers. This way we can
finally drop the machine operators from the JS graph level
completely in TurboFan.

Also drop the funky JSLoadDynamic operator from TurboFan,
which was by now just a small wrapper around the runtime
call to %LoadLookupSlot.

R=mstarzinger@chromium.org

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

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

Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic

Marking as undetectable makes abstract equality of null, undefined, and
other undetectable objects easier. Supporting it in the generic compare
IC significantly speeds up dynamic comparison between those values and
JSReceivers by not falling back to the runtime.

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

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

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

By now only the default %TypedArray%.prototype.sort compare function
and the JS implementation of SameValueZero were still using the odd
%_IsMinusZero intrinsic, whose semantics both included a number check
(actually HeapNumber test) plus testing if the heap number stores the
special -0 value. In both cases we already know that we deal with
number so we can reduce it to a simple number test for -0, which can
be expressed via dividing 1 by that value and checking the sign of
the result. In case of the compare function, we can be even smarter
and work with the reciprocal values in case x and y are equal to 0
(although long term we should probably rewrite the fast case for
the typed array sorting function in C++ anyway, which will be way,
way faster than our handwritten callback-style, type-feedback
polluted JS implementation).

R=yangguo@chromium.org

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

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

The flag in question is a debug-only flag supported by full-codegen and
Crankshaft only. In it's current form there are some unresolved issues:
- The flag is defeated by inlining in Crankshaft.
- The flag is not supported by TurboFan.
- The flag is not supported by Ignition.

Instead of addressing the above issues and increasing maintenance cost
for all backends and also given the "slim" test coverage, this CL fully
removes the support from all backends.

R=bmeurer@chromium.org,jkummerow@chromium.org

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

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

This allows us to remove the somewhat awkward BuildLoadObjectField
from the AstGraphBuilder and also allows us to simplify fullcodegen
for class literals.

R=mstarzinger@chromium.org

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

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

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.

R=jarin@chromium.org, rmcilroy@chromium.org
TBR=rossberg@chromium.org
BUG=v8:2159
LOG=n

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

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