This removes some leftover code which avoided adding stack checks to
stubs being compiled via the normal JavaScript pipeline, which we no
longer do.

R=bmeurer@chromium.org

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

R=littledan@chromium.org
BUG=v8:5339

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

This implements https://github.com/tc39/ecma262/pull/627/.

BUG=v8:5360

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

R=littledan@chromium.org
BUG=v8:5339

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

Extract the call counts from the type feedback vector during graph
building (either via the AstGraphBuilder or the BytecodeGraphBuilder),
and put them onto the JSCallFunction and JSCallConstruct operators,
so that they work even across inlinine through .apply and .call (which
was previously hacked by creating a temporary type feedback vector
for those).

The next logic step will be to make those call counts into real
relative call frequencies (also during graph building), so that we
can make inlining decisions that make sense for the function being
optimized (where absolute values are misleading).

R=jarin@chromium.org
BUG=v8:5267,v8:5372

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

Rolling v8/build to 4e62debd8bf6e75229861c7b8b352953f8bfec2e

Rolling v8/buildtools to b97d6c93a3e805c9ba5356dca872f1801639fbc5

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to f010dd827c6d3a8ec2f355168fc4342ba39a78f8

Rolling v8/third_party/icu to b0bd3ee50bc2e768d7a17cbc60d87f517f024dbe

Rolling v8/tools/clang to 23638ab6411fb9e25ea7f1837835b67a793b5499

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

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

BUG=

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

Revert of [heap] Enable black allocation when finalizing incremental marking. (patchset #6 id:100001 of https://codereview.chromium.org/2239733002/ )

Reason for revert:
Suspecting this is a roll blocker: https://codereview.chromium.org/2332343002/

#
# Fatal error in ../../v8/src/heap/spaces.h, line 1618
# Check failed: capacity_ >= bytes (25429824 vs. 18446744073709551168).
#

Original issue's description:
> [heap] Enable black allocation when finalizing incremental marking.
>
> BUG=chromium:630386
>
> Committed: https://crrev.com/1ccc742dc326b063999670421e1da0ea124874c0
> Cr-Commit-Position: refs/heads/master@{#39382}

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

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

json-parser does the same thing. This drastically reduces GC cost when
deserializing objects large enough that multiple collections are likely
(since it saves the effort to move them to the old generation, when we
know that the objects we create will persist at least until the deserializer
finishes).

The threshold was chosen to match json-parser.

This patch reduces deserialization time on a large blob of JSON-y data
by approximately 30%.

BUG=chromium:148757

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

v8::Isolate::Throw only schedules the exception; it is necessary to promote it
after invoking the delegate.

BUG=chromium:148757

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

Handle some examples of the "asynchronous case" by marking await expressions
as either caught or uncaught; in the caught case, this marks the Promise passed
in as having a catch predicted. The marking is done in AST numbering, which
chooses between two different runtime function calls based on catch prediction.

BUG=v8:5167

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

The initial support for low level exception handling in Wasm will not
support finally blocks. This decision is taken for both simplicity (
handling finallys is not straightforward if we want try blocks to yield
values), and lack of good use case (clang++ does not need them.) They
may be added in the future once we understand the implications of
having them.

BUG=

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

R=rmcilroy@chromium.org
BUG=

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

This CL "weakens" the typer somewhat, as it was querying aspects of
Type that are within the representation dimension. It's not the right
place to do that.

BUG=

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

This reverts commit cf5180c3. It turns
out finally blocks aren't useful in the current incarnation of Wasm. We
might reintroduce it later.

BUG=

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

LOG=N
BUG=v8:4124

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

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

The AllocationResult already carries the information in which space the allocation failure happened.
BUG=

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

During GC multiple threads can request icache flush when evacuating
code space in parallel.

Simulator::FlushICache updates Isolate::simulator_icache hashmap,
which leads to a race.

This patch adds a lock for simulator_icache.

BUG=

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

This adds a regression test for a bug where {OsrPoll} instructions
within the bytecode stream ended up outside of actual loops. This has
been fixed already, by merging {OsrPoll} into the backwards branch.

R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645888
BUG=chromium:645888

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

This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.

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

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

BUG=

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

BUG=chromium:630386

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

When lowering DataField accesses, we should pay attention to the
MachineRepresentation reported by the AccessInfo. This doesn't
yet change the rest of the pipeline to take full advantage of
the representations.

Drive-by-fix: Make the code more robust, especially the part that
deals with mutable heap number access.

R=mvstanton@chromium.org
BUG=v8:5267,v8:5270

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

BUG=chromium:630386

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

When inlining sloppy functions try to find some witness in the effect
chain that the receiver is already a JSReceiver and thereby avoid
inserting the JSConvertReceiver node, which we currently cannot really
optimize away most of the time.

Middle-term we may want to change the way CheckMaps works and have some
unified mechanism to deal with effect chain walks to find witnesses for
various map related facts. Also we may want to consider doing this
optimization later, although that requires some more refactorings since
we already promised that JSConvertReceiver gives a Type::Receiver.

R=mstarzinger@chromium.org
BUG=v8:5267

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

Moves the context chain search loop out of generated bytecode, and into
the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
an additional operand. This should decrease the bytecode size and
increase performance for deep context chain searches, at the cost of
slightly increasing bytecode size for shallow context access.

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

To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well).

BUG=

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

BUG=v8:5269

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

BUG=

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

We check for external memory limit in Heap::ReportExternalMemoryPressure.

BUG=chromium:616434

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

This makes sure OSR entry points can be added without having special
{OsrPoll} instructions in the bytecode stream. Eventually we might end
up merging back-branches and OSR polls together. Any loop header can be
used as an OSR entry point.

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

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

BUG=v8:5269

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

Don't sort inline candidates by comparing Node pointers, where the order
depends on the allocation order and the concrete Zone memory layout at
runtime. Instead sort based on NodeId, which is deterministic.

R=mvstanton@chromium.org
BUG=v8:5267

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

BUG=chromium:474921
NOTRY=true

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

BUG=chromium:474921
NOTRY=true

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

Also unify the Pow implementation somewhat. There are still some
inconsistencies with the FPU version for x64/ia32, but that has
to be resolved separately.

R=ahaas@chromium.org, mvstanton@chromium.org
BUG=v8:5086

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

BUG=chromium:474921
NOTRY=true

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

Add strength reduction rules to optimize

 CheckTaggedSigned(CheckTaggedSigned(x)) -> CheckTaggedSigned(x)

and

 CheckTaggedPointer(CheckTaggedPointer(x)) -> CheckTaggedPointer(x)

where we do some cleanup optimizations after loop peeling and redundancy
elimination, which can generate these constructs.

BUG=v8:5267

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

Reduce compilation time (with clang) for opcodes-unittest.cc from
1m38s to roughly 1s by not overusing the macro expansion magic.

TBR=jarin@chromium.org

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