This CL fixed one bug in crankshaft compiler for Math.max(-0, 0).

BUG=

Review-Url: https://codereview.chromium.org/2175243002
Cr-Commit-Position: refs/heads/master@{#38079}

Review-Url: https://codereview.chromium.org/2183373002
Cr-Commit-Position: refs/heads/master@{#38078}

The new phase will detect loop variable, infer bounds and bake them into
the type.

Review-Url: https://codereview.chromium.org/2164263003
Cr-Commit-Position: refs/heads/master@{#38077}

Introduce the CheckString during native context specialization when we
have string map feedback on a LOAD_IC/STORE_IC. The CheckString
operator, just like its CheckNumber pendant, renames the input and
assigns a proper type, which we will use soon to lower access operations
on Strings, i.e. charCodeAt calls or keyed accesses.

R=jarin@chromium.org
BUG=v8:4930,v8:5141

Review-Url: https://codereview.chromium.org/2181943003
Cr-Commit-Position: refs/heads/master@{#38076}

Rolling v8/build to 603acacfd82e28d442da5e24bf22bbacbeefa589

Rolling v8/buildtools to 67bf0653b2eb9eabd4fc17c4bf2df828e904a558

Rolling v8/third_party/android_tools to af1c5a4cd6329ccdcf8c2bc93d9eea02f9d74869

Rolling v8/tools/clang to a98f7fa326ac2b7e1710e923c1287cde7f901d86

Rolling v8/tools/mb to 93a755bd710560a2db62300d69db0d8876c01442

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

Review-Url: https://codereview.chromium.org/2191433002
Cr-Commit-Position: refs/heads/master@{#38075}

Revert of [Tracing] V8 Tracing Controller (patchset #11 id:200001 of https://codereview.chromium.org/2137013006/ )

Reason for revert:
Revert this CL due to V8 Arm Builder failure and V8 Mips Builder failure.

https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2456

https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/2506

Original issue's description:
> [Tracing] V8 Tracing Controller
>
> V8 has had a trace event macro interface for while, but without a tracing
> controller a standalone V8 would be unable to collect traces.
>
> This CL introduces a complete Tracing Controller system for V8.
> It is fully function except that it does not yet store trace event args.
>
> This CL has a few components,
> The tracing controller itself, contributed by the author of this CL
> The Trace config (including the parser), contributed by lpy@
> The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@
>
> BUG=v8:4561
> LOG=N
>
> Committed: https://crrev.com/3d598452679ce208ad9b2f48e0fb3fae352ce375
> Cr-Commit-Position: refs/heads/master@{#38073}

TBR=jochen@chromium.org,mattloring@google.com,rskang@google.com,yangguo@chromium.org,fmeawad@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4561

Review-Url: https://codereview.chromium.org/2183943002
Cr-Commit-Position: refs/heads/master@{#38074}

V8 has had a trace event macro interface for while, but without a tracing
controller a standalone V8 would be unable to collect traces.

This CL introduces a complete Tracing Controller system for V8.
It is fully function except that it does not yet store trace event args.

This CL has a few components,
The tracing controller itself, contributed by the author of this CL
The Trace config (including the parser), contributed by lpy@
The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@

BUG=v8:4561
LOG=N

Review-Url: https://codereview.chromium.org/2137013006
Cr-Commit-Position: refs/heads/master@{#38073}

BUG=chromium:631094
R=hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2176393003
Cr-Commit-Position: refs/heads/master@{#38072}

Revert of [debugging] print ranges for consecutive values with %DebugPrint (patchset #2 id:20001 of https://codereview.chromium.org/2169143003/ )

Reason for revert:
breaks android build due to uninitialized variable.
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug%20builder/builds/2034

Original issue's description:
> [debugging] print ranges for consecutive values with %DebugPrint
>
> With this CL repeated values in elements are combined into a single printout with a range.
>
> BEFORE:
> - elements = {
>   0: <undefined>
>   1: <undefined>
>   2: <the_hole>
> }
>
> AFTER:
>  - elements = {
>        0-1: <undefined>
>          2: <the_hole>
> }
>
> BUG=
>
> Committed: https://crrev.com/ec4165742088043d8fede38db21a281e16682adb
> Cr-Commit-Position: refs/heads/master@{#38069}

TBR=yangguo@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/2181093003
Cr-Commit-Position: refs/heads/master@{#38071}

This ports 9c59539f / r37803 to KeyedLoadICs.

Review-Url: https://codereview.chromium.org/2182103002
Cr-Commit-Position: refs/heads/master@{#38070}

With this CL repeated values in elements are combined into a single printout with a range.

BEFORE:
- elements = {
  0: <undefined>
  1: <undefined>
  2: <the_hole>
}

AFTER:
 - elements = {
       0-1: <undefined>
         2: <the_hole>
}

BUG=

Review-Url: https://codereview.chromium.org/2169143003
Cr-Commit-Position: refs/heads/master@{#38069}

The showed up unnaturally high while profiling DOM node creation.

BUG=chromium:630217

Review-Url: https://codereview.chromium.org/2181323002
Cr-Commit-Position: refs/heads/master@{#38068}

BUG=chromium:631094
R=hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2181373002
Cr-Commit-Position: refs/heads/master@{#38067}

BUG=chromium:631094

Review-Url: https://codereview.chromium.org/2181333002
Cr-Commit-Position: refs/heads/master@{#38066}

Port 580fdf3c

This also reverses the MachineType stored for partial unaligned access support
such that it records the unsupported types, rather than supported types.

BUG=

Review-Url: https://codereview.chromium.org/2182493003
Cr-Commit-Position: refs/heads/master@{#38065}

This adds tracking of the loop depth to the {BytecodeGenerator} in order
to statically determine the loop nesting level for {OsrPoll} bytecodes.

R=rmcilroy@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2176183002
Cr-Commit-Position: refs/heads/master@{#38064}

PPC/s390: Reland of [interpreter] Add explicit OSR polling bytecode. (patchset #1 id:1 of https://codereview.chromium.org/2184553003/ )

Port e1ad114e

Original commit message:

    Reason for revert:
    Fix has been landed.

    Original issue's description:
    > Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ )
    >
    > Reason for revert:
    > Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ?
    >
    > E.g.:
    > https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
    >
    > Original issue's description:
    > > [interpreter] Add explicit OSR polling bytecode.
    > >
    > > This adds an explicit {OsrPoll} bytecode into every loop header which
    > > triggers on-stack replacement when armed. Note that each such bytecode
    > > stores the static loop depths as an operand, and hence can be armed for
    > > specific loop depths.
    > >
    > > This also adds builtin code that triggers OSR compilation and switches
    > > execution over to optimized code in case compilation succeeds. In case
    > > compilation fails, the bytecode dispatch just continues unhindered.
    > >
    > > R=rmcilroy@chromium.org
    > > TEST=mjsunit/ignition/osr-from-bytecode
    > > BUG=v8:4764
    > >
    > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
    > > Cr-Commit-Position: refs/heads/master@{#38043}
    >
    > TBR=rmcilroy@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:4764
    >
    > Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc
    > Cr-Commit-Position: refs/heads/master@{#38044}

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4764
LOG=N

Review-Url: https://codereview.chromium.org/2182173002
Cr-Commit-Position: refs/heads/master@{#38063}

Revert of [release] Change blink trybot name on v8 roll CLs (patchset #1 id:1 of https://codereview.chromium.org/2185513002/ )

Reason for revert:
Revert,  because blink tryserver bot rename is reverted.

BUG=chromium:631448

Original issue's description:
> [release] Change blink trybot name on v8 roll CLs
>
> BUG=chromium:590036
> NOTRY=true
>
> Committed: https://crrev.com/a5fae1039409864295b42a6f33cef85ca9396bda
> Cr-Commit-Position: refs/heads/master@{#38041}

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

Review-Url: https://codereview.chromium.org/2186593003
Cr-Commit-Position: refs/heads/master@{#38062}

BUG=

Review-Url: https://codereview.chromium.org/2178363003
Cr-Commit-Position: refs/heads/master@{#38061}

Increased array size in the testcase such that the chunk size is
greater that the page size on PPC (4MB). This fixes the case when
(start + Page::kPageSize) memory location is tested to be part of
the chunk.
The testcase was added as part of https://codereview.chromium.org/2110213003/

R=ulan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2182113002
Cr-Commit-Position: refs/heads/master@{#38060}

This is a first step towards a perfect world where a call interface descriptor is the only place that defines calling convention for a particular code stub.

Review-Url: https://codereview.chromium.org/2172223002
Cr-Commit-Position: refs/heads/master@{#38059}

BUG=chromium:631158

Review-Url: https://codereview.chromium.org/2185623002
Cr-Commit-Position: refs/heads/master@{#38058}

BUG=630969,630386
LOG=n

Review-Url: https://codereview.chromium.org/2185613002
Cr-Commit-Position: refs/heads/master@{#38057}

Reland of [interpreter] Add explicit OSR polling bytecode. (patchset #1 id:1 of https://codereview.chromium.org/2184553003/ )

Reason for revert:
Fix has been landed.

Original issue's description:
> Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ )
>
> Reason for revert:
> Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ?
>
> E.g.:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
>
> Original issue's description:
> > [interpreter] Add explicit OSR polling bytecode.
> >
> > This adds an explicit {OsrPoll} bytecode into every loop header which
> > triggers on-stack replacement when armed. Note that each such bytecode
> > stores the static loop depths as an operand, and hence can be armed for
> > specific loop depths.
> >
> > This also adds builtin code that triggers OSR compilation and switches
> > execution over to optimized code in case compilation succeeds. In case
> > compilation fails, the bytecode dispatch just continues unhindered.
> >
> > R=rmcilroy@chromium.org
> > TEST=mjsunit/ignition/osr-from-bytecode
> > BUG=v8:4764
> >
> > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> > Cr-Commit-Position: refs/heads/master@{#38043}
>
> TBR=rmcilroy@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:4764
>
> Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc
> Cr-Commit-Position: refs/heads/master@{#38044}

TBR=rmcilroy@chromium.org,machenbach@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2184713002
Cr-Commit-Position: refs/heads/master@{#38056}

So far we didn't really recognize leaq, but only leal instructions in
the x64 InstructionSelector. Now that we actually generate more of them,
we should also pay more attention to those.

R=epertoso@chromium.org

Review-Url: https://codereview.chromium.org/2186573002
Cr-Commit-Position: refs/heads/master@{#38055}

BUG=chromium:629806

Review-Url: https://codereview.chromium.org/2187433002
Cr-Commit-Position: refs/heads/master@{#38054}

The bug was caused when validating expressions

X >> 0

for indexing into 8-bit heap views. If X was not an intish, the 'normal'
validation path would fail. That, however, left the type of X registered
in the AsmTyper::node_types_ member.

Later, in the 'lenient' code path for 8-bit views, the entire X >> 0
expression would be validated, which would cause X to be validated
again, at which point AsmTyper::SetTypeOf() would DCHECK because the
supplied node already had a type associated with it.

The fix was to simply FAIL() when X is not an intish. This is safe
because if X is not an intish, then

Validate(>>, !intish, FixNum)

will also fail.

BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=628803
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
TEST= cctest/asmjs/test-asm-typer.cc
LOG= N

Review-Url: https://codereview.chromium.org/2181723002
Cr-Commit-Position: refs/heads/master@{#38053}

R=rmcilroy@chromium.org
TEST=cctest/test-bytecode-generator
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2184663002
Cr-Commit-Position: refs/heads/master@{#38052}

This allows us to fuse the address computation with the actual memory
access operation on x64, which reduces the register pressure and the
number of instructions. There's probably some follow up cleanup that has
to happen to make sure the machine operator optimizations that are
relevant to word64 computations are also available (similar to what is
already available for word32).

R=epertoso@chromium.org

Review-Url: https://codereview.chromium.org/2183043002
Cr-Commit-Position: refs/heads/master@{#38051}

With the current approach we cannot eliminate context accesses in
mid-size function contexts, so let's bump the limit a bit to make
sure we can optimize those as well.

R=jarin@chromium.org
BUG=v8:4930,v8:5141

Review-Url: https://codereview.chromium.org/2182973004
Cr-Commit-Position: refs/heads/master@{#38050}

This works around the problem that the lowering for JSStackCheck doesn't
play well with effect chain based state tracking, because it doesn't
report the correct changes (we will address this with a better handling
of stack checks soon).

It also allows us to run the EarlyOptimizationPhase concurrently, which
doesn't need to access the heap or generate code stubs.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2183033002
Cr-Commit-Position: refs/heads/master@{#38049}

BUG=chromium:474921

Review-Url: https://codereview.chromium.org/2182933002
Cr-Commit-Position: refs/heads/master@{#38048}

BUG=chromium:625894

Review-Url: https://codereview.chromium.org/2181303002
Cr-Commit-Position: refs/heads/master@{#38047}

This feature has not been used in the past few years and most likely does not
even work anymore.

R=ishell@chromium.org

Review-Url: https://codereview.chromium.org/2186533002
Cr-Commit-Position: refs/heads/master@{#38046}

BUG=
R=danno

Review-Url: https://codereview.chromium.org/2171543004
Cr-Commit-Position: refs/heads/master@{#38045}

Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ )

Reason for revert:
Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ?

E.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607

Original issue's description:
> [interpreter] Add explicit OSR polling bytecode.
>
> This adds an explicit {OsrPoll} bytecode into every loop header which
> triggers on-stack replacement when armed. Note that each such bytecode
> stores the static loop depths as an operand, and hence can be armed for
> specific loop depths.
>
> This also adds builtin code that triggers OSR compilation and switches
> execution over to optimized code in case compilation succeeds. In case
> compilation fails, the bytecode dispatch just continues unhindered.
>
> R=rmcilroy@chromium.org
> TEST=mjsunit/ignition/osr-from-bytecode
> BUG=v8:4764
>
> Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> Cr-Commit-Position: refs/heads/master@{#38043}

TBR=rmcilroy@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:4764

Review-Url: https://codereview.chromium.org/2184553003
Cr-Commit-Position: refs/heads/master@{#38044}

This adds an explicit {OsrPoll} bytecode into every loop header which
triggers on-stack replacement when armed. Note that each such bytecode
stores the static loop depths as an operand, and hence can be armed for
specific loop depths.

This also adds builtin code that triggers OSR compilation and switches
execution over to optimized code in case compilation succeeds. In case
compilation fails, the bytecode dispatch just continues unhindered.

R=rmcilroy@chromium.org
TEST=mjsunit/ignition/osr-from-bytecode
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2172233002
Cr-Commit-Position: refs/heads/master@{#38043}

Doing so in a -pie build would make the snapshot non-deterministic.

R=bmeurer@chromium.org
BUG=v8:5233

Review-Url: https://codereview.chromium.org/2178093003
Cr-Commit-Position: refs/heads/master@{#38042}

BUG=chromium:590036
NOTRY=true

Review-Url: https://codereview.chromium.org/2185513002
Cr-Commit-Position: refs/heads/master@{#38041}

This flag is aiming at shipping the ability to generate optimized code
directly from bytecode (without re-parsing source code). All features
needed to ship such a configuration will be staged behind this flag.

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

Review-Url: https://codereview.chromium.org/2174333002
Cr-Commit-Position: refs/heads/master@{#38040}