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}

Fix failure in mjsunit/wasm/embenchen/box2d on 32-bit architectures that do not support unaligned access.

This test fails because WasmGraphBuilder::BuildCFuncInstruction allocates
space for doubles using StackSlot turbofan operator, but this space is not
guaranteed to be 8 bytes aligned if SP itself is not 8 bytes aligned (which
is the case on 32-bit architectures).

BUG=mjsunit/wasm/embenchen/box2d

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

When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.

This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.

Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.

R=yangguo@chromium.org
BUG=chromium:631318

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

Revert of MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.' (patchset #2 id:20001 of https://codereview.chromium.org/2171303002/ )

Reason for revert:
This bug has an error in the toolchain.gypi file, the conditions clause is repeated. This has broken the DrMemory builder - see first failing chromium build https://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20Windows%20Builder%20%28DrMemory%29/builds/17857 which included a v8 roll.

For reference the errors are:
gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\d8.gyp

gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\v8.gyp

gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\samples\samples.gyp

Original issue's description:
> MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.'
>
> Port 6470ddad
>
> On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used.
>
> Original commit message:
> 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=
>
> Committed: https://crrev.com/52f2ceb052f63324050c7a098e4398f510b54763
> Cr-Commit-Position: refs/heads/master@{#38030}

TBR=jarin@chromium.org,machenbach@google.com,akos.palfi@mattakis.com,ivica.bogosavljevic@imgtec.com,marija.antic@imgtec.com,ilija.pavlovic.imgtec@gmail.com,akos.palfi@imgtec.com,machenbach@chromium.org,balazs.kilvady@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

TBR=machenbach

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

Rolling v8/build to cce24bcaab6481f479f4baf00b5ea36d78268bcd

Rolling v8/tools/mb to 11aa1bbe1b4fbae3694d14eb59b4eb98550bcbee

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

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

This slightly simplifies scope handling. It also makes it possible to
implement some potential future changes to classes purely in the parser
by adding additional code to the DoExpression.

This is a portion of https://codereview.chromium.org/2142333002/, which
probably isn't going through in full.

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

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

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

This prepares for switching arm64 sim to gn.

BUG=chromium:474921

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

Reduces the dark matter of reported fixed arrays to < 5%.

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

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

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

Port 6470ddad

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

Original commit message:
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=

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

On AIX clock_gettime provides CPU time with a resolution of
10ms, which causes the ThreadTicks testcase to fail since at
the 2 instances the CPU time of the thread outputs to 0.
Using AIX's API thread_cputime instead which provides CPU
time with a resolution of 1ns.
The testcase was added as part of https://codereview.chromium.org/1976603005

R=jochen@chromium.org, lpy@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/2174003002
Cr-Commit-Position: refs/heads/master@{#38029}

The testcase allocates JSArraybuffer on 2 separate pages which should be
on the New space. In the testcase semi space size is set to 2MB.
Since page size on PPC is 4MB the semi new space size defaults to 4MB.
Therefore when allocating 2nd buffer, scavenge GC kicks in as from-space is
filled up and copies 1st buffer to to-space. Now, the 2nd buffer also gets
allocated on the same to-space, therefore both buffer end up being on the
same page. This fix should allocate enough semi new space to contain 2
pages (for all platform).
The testcase was added as part of https://codereview.chromium.org/2036643002

R=mlippautz@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/2167853002
Cr-Commit-Position: refs/heads/master@{#38028}

/ also selects the search box.

BUG=

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

The tests array-concat-revoked-proxy-*.js are copied out from array-concat.js,
in order to verify that they work correctly with a valid ArrayProtector cell.

These tests pass with https://crrev.com/122a9b7af02606dae558336082ab139a87eba39d
applied, but fail without it.

BUG=v8:5134
R=neis@chromium.org, cbruni@chromium.org, littledan@chromium.org

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

BUG=
R=danno

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

If you dragged the node out of the bounding box, this commit allows you to see
it again after you zoom. The zoom looks jittery, but I think it's better than
not being able to see it at all.

BUG=
R=danno

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

Rolling v8/build to bd9b7568ac244046c38f6c27d686d7661bfd4d27

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

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

Failure is due to different endianness on big endian. The test now passes on
both big-endian and little-endian architectures.

TEST=cctest/test-code-stubs-mips64/ConvertDToI
BUG=

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