Additionally list C++ builtins as well under --runtime_call_stats.
Let's try to keep all counters in one place, that makes it a bit
easier to maintain and especially discard unused ones.

BUG=

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

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

R=rmcilroy@chromium.org

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

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

This adds test cases for exception handlers that require a context
switch when entering the catch-block or the finally-block, triggered
through nested contexts within the try-block.

R=jarin@chromium.org

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

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

BUG=v8:4280,v8:4682
LOG=N
R=rmcilroy@chromium.org

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

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

Improve instruction selector for mask and shift operations by using cheaper
instructions where possible, in preference to UBFX.

BUG=

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

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

BUG=v8:4280
LOG=N

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

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

BUG=chromium:578883
LOG=NO

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

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

BUG=chromium:580971
LOG=n

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

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

The function in question can already return an empty handle in the case
of failures. This makes that contract explicit by using MaybeHandle like
all other compiler API functions.

R=yangguo@chromium.org

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

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

When doing advance at the start of an unanchored unicode regexp,
we do not have to care about surrogate pairs. If we actually advance
into the middle of a surrogate pair, the only choice is to also
consume trail surrogate as nothing else can match from there.

This reduces the emitted code slightly. By not having choice in the
loop, we do not have to push backtrack onto the stack, preventing
stack overflow.

R=erik.corry@gmail.com, erikcorry@chromium.org

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

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

R=bmeurer@chromium.org

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

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

This is a temporary workaround for bytecodes which are not guaranteed
to actually use the frame states being created for them. One example
for this are runtime calls to intrinsics, or to runtime functions for
which the frame state count is zero in Linkage::FrameStateInputCount.

This will eventually be reworked into a more generic mechanism that
attaches frame states in the BytecodeGraphBuilder::VisitBytecodes
iteration method itself, instead of in the individual visitors.

R=jarin@chromium.org

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

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

Revert of [builtins] Remove bunch of uses of %_Arguments and %_ArgumentsLength. (patchset #1 id:1 of https://codereview.chromium.org/1678953004/ )

Reason for revert:
Breaks tree

Original issue's description:
> [builtins] Remove bunch of uses of %_Arguments and %_ArgumentsLength.
>
> There are a bunch of places in our builtins where we use %_Arguments and
> %_ArgumentsLength for no good reason, as arguments object and/or rest
> parameter is as good and performant in these cases. Now the only uses
> of %_Arguments and %_ArgumentsLength left are in string.js, which
> requires dedicated investigation.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/2160429fd458e3c095475e718c97f77ac90d906f
> Cr-Commit-Position: refs/heads/master@{#33834}

TBR=yangguo@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/1677063005

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

There are a bunch of places in our builtins where we use %_Arguments and
%_ArgumentsLength for no good reason, as arguments object and/or rest
parameter is as good and performant in these cases. Now the only uses
of %_Arguments and %_ArgumentsLength left are in string.js, which
requires dedicated investigation.

R=yangguo@chromium.org

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

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

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}

Rolling v8/tools/clang to fa731f3e12b54c519e08c0fe9b26cf12274df20c

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

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

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

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

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

Port 2166bd8c

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

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

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

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
    xwhich is used in both TurboFan and Ignition.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:2159
LOG=n

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

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

To bring V8 into line with the proposed design changes in:

 https://github.com/WebAssembly/design/pull/489

(This CL is forked from https://codereview.chromium.org/1634673002/.
That CL doesn't merge cleanly, and I can't update it.)

TBR=titzer@chromium.org
LOG=Y
BUG=chromium:575167

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

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

This patch moves Symbol.species support to the "experimental JavaScript
features" flag. While @@species is still a performance hit, it doesn't seem
like it would make the web unusably slow; shipping would still have to
wait on fixing the performance regression, but staging this version should
yield valuable web compatibility information.

R=cbruni
BUG=v8:4093
LOG=Y

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

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

ES2016 TypedArray subclassing semantics break the Node.js Buffer module,
also used on the web. I wrote a pull request against the web and Node
versions to fix the issue, but the pull request has not yet been granted,
and this is blocking shipping the change. For now, this patch extends the
web compatibility workaround to the --harmony-species flag, so that
Symbol.species and associated subclassing semantics can ship independently.

R=cbruni
BUG=v8:4665
LOG=Y

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

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

Port 187b3f28

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

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

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

TEST=cctest/test-interpreter/InterpreterTryCatch,
     cctest/test-run-bytecode-graph-builder/BytecodeGraphBuilderTryCatch,
     cctest/test-run-bytecode-graph-builder/BytecodeGraphBuilderTryFinally2

BUG=

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

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

Port bb883395

Original commit message:
    This replaces the global remembered set with per-page remembered sets.

    Each page in the old space, map space, and large object space keeps track of
    the set of slots in the page pointing to the new space.

    The data structure for storing slot sets is a two-level bitmap, which allows
    us to remove the store buffer overflow and SCAN_ON_SCAVENGE logic.

    Design doc: https://goo.gl/sMKCf7

R=ulan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:578883
LOG=NO

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

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

Do not rely on elapsed time to collect enough samples.
Use CollectSample API function instead.

Remove checks for extra functions present in a profile, as
there in fact can be lots of native support functions.

BUG=v8:2999
LOG=N

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

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

Also replace SKIPS by FAIL to ensure tests are reenabled once they work.

BUG=v8:4680
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm64_dbg,v8_linux_arm_dbg

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

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

This allows us to remove the somewhat awkward BuildLoadObjectField
from the BytecodeGraphBuilder and also allows us to simplify the
bytecode stream for class literals.

R=oth@chromium.org

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

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

Adds implementation and tests to support const/let variables in the
interpreter.

BUG=v8:4280,v8:4679
LOG=N

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

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

Previously, Object.values() and Object.entries() were piggy-backing on
Object.keys(). This meant that they would pre-filter non-enumerable properties,
violating the runtime behaviour of the methods. Unfortunately, this does not
match the current proposal text.

Also incorporates several tests verifying this behaviour based on tests included
in the ChakraCore implementation.

In this reland, the new patch fills up the longer-lasting FixedArray with
`undefined` to avoid the crash in Heap::Verify().

Originally reviewed at https://codereview.chromium.org/1637753004

BUG=v8:4663
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org

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

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

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}

Generally we only care whether the next object is a hidden prototype.
It's simpler to check whether the current object has a hidden prototype
instead of walking to the next prototype and checking its map.

BUG=

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

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

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}

Revert of Do not eagerly instantiate accessors' JSFunction. (patchset #9 id:180001 of https://codereview.chromium.org/1609233002/ )

Reason for revert:
[Sheriff] Breaks gcmole:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gcmole/builds/6260

Original issue's description:
> Do not eagerly instantiate accessors' JSFunction.
>
> BUG=
>
> Committed: https://crrev.com/4d46b510caf534d770ce19a01a11b8796304471b
> Cr-Commit-Position: refs/heads/master@{#33812}

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

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

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

This moves the JSCreate related functionality from JSTypedLowering into
a dedicated JSCreateLowering reducer. This is in preparation of landing
the support for optimized literals in TurboFan, which would blow up
JSTypedLowering quite seriously otherwise.

R=mstarzinger@chromium.org

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

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

BUG=

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

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

BUG=

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

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

The serializer collects objects in iteration order, not in allocation
order. This means that the deserializer will put these objects in
iteration order onto the reserved pages as well. There is no guarantee
that objects that were on the first page will end up on the first page
after deserialization.

Until now we got lucky, since we only ever need one space per page for
the default snapshot. For roots, the iteration order and allocation
order also do not differ enough to cause any issue for immortal
immovable root objects. These objects need to stay on the first page of
its allocated space to not move.

However, let's make sure it stays this way, and we realize soon enough
if this assumption does not hold.

R=mstarzinger@chromium.org

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

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

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}

Fix failures on MIPS simulator because incomplete
handling of MTHC1 and MFHC1 in Fp32 mode
Fix failures on older kernels that have problems with
MTHC1 and MFHC1 in kernel FPU emulation

Original issue's description:
> Revert of MIPS: Add FPXX support to MIPS32R2 (patchset #3
> id:40001 of https://codereview.chromium.org/1586223004/ )
>
> Reason for revert:
> Revert patch due to a number of failures appearing on the > MIPS v8 simulator
>
> Original issue's description:
>> MIPS: Add FPXX support to MIPS32R2
>>
>> The JIT code generated by V8 is FPXX compliant
>> when v8 compiled with FPXX flag. This allows the code to
>> run in both FP=1 and FP=0 mode. It also alows v8 to be used
>> as a library by both FP32 and FP64 binaries.
>>
>> BUG=
>>
>> Committed: https://crrev.com/95110dde666158a230a823fd50a68558ad772320
>> Cr-Commit-Position: refs/heads/master@{#33576}

BUG=

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

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