Port 52f2ceb0

Original commit message:
On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used.

This introduces SilenceNaN operator, which makes sure that we only
store quiet NaNs into holey arrays. We omit the NaN silencing code
at instruction selection time if the input is an operation that
cannot possibly produce signalling NaNs.

BUG=
TEST=mjsunit/compiler/regress-store-holey-double-array

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

This prepares for https://codereview.chromium.org/2188693002/

With the current configuration, sanitizers wouldn't be used
at all. The clang configuration is automatically derived
in GN.

BUG=chromium:474921
NOTRY=true

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

Also run the BranchElimination (plus CommonOperatorReducer and the
DeadCodeElimination) during the load elimination phase, so we can
elminate some Phi nodes early on that would otherwise confuse the
truncation analysis and/or representation selection, i.e. if there's a
branch that is never taken, that would yield undefined, we'd have to
choose tagged representation for the Phi, even if the always taken
branch yields an integer.

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

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

R=marja@chromium.org
BUG=chromium:621361

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

This required the introduction of the CheckedNumberOrOddballAsWord32 use info, and a change in the RepresentationChanger to handle it.

BUG=

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

R=mythria@chromium.org
TEST=mjsunit/regress/regress-2618
BUG=v8:4764

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

Using PIE switches on ASLR. With mksnapshot, this can lead
to non-deterministic snapshots.

BUG=v8:5233

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

This implements graph construction for entry via on-stack replacement
within the {BytecodeGraphBuilder}. Entry points are at loop headers
similar to previous OSR implementations. All interpreter registers are
addressable via {OsrValue} nodes in the graph. Currently we rely on
{OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
targets of back edges).

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

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

BUG=chromium:474921
NOTRY=true

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

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

Reland of [debugging] print ranges for consecutive values with %DebugPrint (patchset #1 id:1 of https://codereview.chromium.org/2181093003/ )

Reason for revert:
Dummy initializing variables to make compilers happy.

Original issue's description:
> 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=
>
> Committed: https://crrev.com/7b2cd8b988d257f22afc7c03cd2caf8ba2e2b3a3
> Cr-Commit-Position: refs/heads/master@{#38071}

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/2182203004
Cr-Commit-Position: refs/heads/master@{#38080}

  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}