R=jochen@chromium.org, verwaest@chromium.org
BUG=chromium:585724
LOG=N

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

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

generate-bytecode-expectations is a tool intended to work together
with test/cctest/test-bytecode-generator.cc in order to produce a
meaningful diff between testcases and the actual bytecode being emitted.

It does so by parsing and compiling Javascript to bytecode,
constructing the same data structure in the testcase and then running a
textual diff between the expected (i.e. the one encoded in the unit test)
and actual (i.e. the one built from the compiler output) representation.

This commit is a first step in this direction, achieving just the first
half of what we desire. At the moment, bytecodechecker can:

* take a code snippet from the command line and emit the expected structure.
* adhere to the same formatting rules of the test cases
  (this one is important for text diff and for copy and pasting too)

Still to do:

* parse unit tests:
    + extract code snippets
    + indent the code to match the input test case
    + allow flexibility in the input format
    + try to recognize and work around some macro magic (i.e. REPEAT_127)
* emit the representation of the constant pool and handlers vector
* run a textual diff

BUG=v8:4280
LOG=N

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

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

R=littledan@chromium.org, verwaest@chromium.org
BUG=v8:4524
LOG=N

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

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

Since https://codereview.chromium.org/1683643002/ null and undefined are
also marked as undetectable. If we anyway need to check for that case,
we can drop the null/undefined checks.

BUG=

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

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

The field in question is only needed when the optimizing compiler is
triggered via OSR. All other paths (e.g. from bytecode stream) should
not rely on the unoptimized code being present.

R=yangguo@chromium.org

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

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

If Array.from is passed an iterable, then it will copy the contents
to the newly created Array (or subclass). The iteration protocol here
includes calling IteratorClose if the loop is exited early due to an
exception thrown. This patch converts Array.from to use a for-of loop
rather than explicitly invoking the iteration protocol so that, when
IteratorClose is invoked on early for-of exit, then Array.from will
call IteratorClose in the appropriate case.

R=neis
LOG=Y
BUG=v8:4739

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

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

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}

Preparing the young generation for (real) non-contiguous backing memory, this
change removes object masks that are used to compute containment in semi and new
space. The masks are replaced by lookups for object tags and page headers, where
possible.

Details:
- Use the fast checks (page header lookups) for containment in regular code.
- Use the slow version that masks out the page start adress and iterates all
  pages of a space for debugging/verification.
- The slow version works for off-heap/unmapped memory.
- Encapsulate all checks for the old->new barrier in Heap::RecordWrite().

BUG=chromium:581412
LOG=N

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

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

This makes sure we can run through the TurboFan pipeline without having
to parse the source when using the bytecode stream as input. This path
is now being tested by the BytecodeGraphTester helper.

R=titzer@chromium.org,rmcilroy@chromium.org

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

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

See https://github.com/tc39/ecma262/pull/331.

R=rossberg
BUG=

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

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

Fix JSLoadGlobal/JSStoreGlobal, JSLoadNamed/JSStoreNamed and
JSLoadProperty/JSStoreProperty to take the current function closure
instead of the type feedback as input, and load the feedback vector
from the closure as required (in JSGenericLowering). There's still
JSLoadDynamic left to be done, and then we don't have any machine
operators in the initial JS graph left.

There'll be more refactoring on the JSGenericLowering in a follow-up
CL, which takes care of the current code duplication and also tries
to use the more efficient LoadIC/KeyedLoadIC instead of the current
LoadICInOptimizedCode/KeyedLoadICInOptimizedCode (and same for store
ICs) whenever possible.

R=jarin@chromium.org

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

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

Rolling v8/build/gyp to 66bbdf4c6b450d55bd9e53fd18d9628a8f328398

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

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

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

This threads the language mode from the bytecode to the node creation
site in the bytecode graph builder. It only adapts the places where such
threading is applicable without considering strong mode. The remaining
uses of the language mode accessors are only required because of strong
mode.

R=mythria@chromium.org

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

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

BUG=

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

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

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

Revert of [turbofan] ARM: Improve AND instruction selection (patchset #1 id:1 of https://codereview.chromium.org/1677023002/ )

Reason for revert:
Possibly causing Mozilla test failures - will investigate.

Original issue's description:
> [turbofan] ARM: Improve AND instruction selection
>
> Improve instruction selector for mask and shift operations by using cheaper
> instructions where possible, in preference to UBFX.
>
> BUG=
>
> Committed: https://crrev.com/53d9c12977f07f55b6f2a72128b8d02c4c857845
> Cr-Commit-Position: refs/heads/master@{#33843}

TBR=bmeurer@chromium.org,jarin@chromium.org,danno@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/1681953003

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

Instead of only sweeping a specific space, let tasks work together once they have
swept their corresponding space.

BUG=

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

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

Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1678973002/ )

Reason for revert:
[Sheriff] Breaks TSAN:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7727

Original issue's description:
> [counters] moving runtime counters to counter.h
>
> 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=
>
> Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225
> Cr-Commit-Position: refs/heads/master@{#33847}

TBR=jarin@chromium.org,cbruni@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/1681923003

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

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}