R=verwaest@chromium.org
BUG=chromium:505370
LOG=N

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

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

Revert "Revert relanded strong property access CL"

Regression issues should be solved. Initial patchset is the original, subsequent patchsets are the fixing modifications.

This reverts commit 4ac7be56.

BUG=v8:3956
LOG=N

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

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

Revert of Let GC select the collector when the external memory allocation limit is reached (patchset #1 id:1 of https://codereview.chromium.org/1201993002/)

Reason for revert:
results in a scavenge storm if scavenge doesn't free enough memory

Original issue's description:
> Let GC select the collector when the external memory allocation limit is reached
>
> BUG=none
> R=hpayer@chromium.org
> LOG=n
>
> Committed: https://crrev.com/93d6216099b60e95bc816bcc913f8f841ee795b6
> Cr-Commit-Position: refs/heads/master@{#29235}

TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=none

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

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

R=dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Also fixes a crankshaft bug with strong implicit conversions.

It turns out that the implicit conversion of oddball values
is smushed into so many places in crankshaft that it would
have been pretty invasive surgery to make everything fall
out naturally.

BUG=v8:3956
LOG=N

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

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

Move the arithmetic shift from Int32MulHigh to a following Int32Add on ARM64.
This graph is commonly generated on reduction of signed integer division.

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

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

BUG=

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

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

This change makes possible to save and restore the FP registers
in the Prologue and Return parts for the CallAddress kind functions.

TEST=test-simplified-lowering/RunNumberDivide_2_TruncatingToUint32,
     test-simplified-lowering/RunNumberMultiply_TruncatingToUint32

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

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

BUG=chromium:504875
R=hpayer@chromium.org
LOG=n

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

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

R=jarin@chromium.org

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

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

R=machenbach@chromium.org
BUG=v8:4135
NOTRY=true
LOG=N

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

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

The deoptimizer (and probably various other places) cannot deal properly
with recursive function inlining, so we disallow it in TurboFan as well.
We might want to reconsider that decision at some point in the future.

R=jarin@chromium.org

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

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

R=ulan@chromium.org

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

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

Reland of https://crrev.com/bf2bbc8ba508ccd21edf3c08d2e4192c4764ae91

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-498022
BUG=chromium:498022
LOG=N

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

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

BUG=

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

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

R=mvstanton@chromium.org
BUG=v8:4132
LOG=N

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

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

BUG=chromium:505007
LOG=N

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

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

Also removed some unused classes.

BUG=

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

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

This has become necessary as we have more experimental natives
that run after deserializing from the snapshot.

R=hpayer@chromium.org
BUG=v8:4200
LOG=N

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

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

Ideally inliner itself should not deal with context specialization at
all, since this is all handled in the pipeline instead (actually
inlining already runs together with context specialization), and the
inlining logic should not care about the specialization mode.

R=jarin@chromium.org

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

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

This optimization never triggers currently, and is inherently native
context dependent for no real reason (for example it will not properly
detect those constructors in the case of cross native context inlining),
plus it is slow and awkward.  In case we really need this functionality
at some point, we should find a way to make it work with the builtin
function id mechanism that is already in place to match other builtins.

R=jarin@chromium.org,rossberg@chromium.org

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

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

R=jarin@chromium.org

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

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

TBR=brucedawson@chromium.org

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

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

This makes sure that the exit control flow that merges the try-block
with the catch-block after a try-catch-statement creates a new merge
node in cases where it has to. Otherwise dangling phi nodes might have
the wrong number of value inputs.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-505354
BUG=chromium:505354
LOG=N

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

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

The failure was been triggered by turning on --harmony-arrays,
maybe because code size was increased or code was added later
in the bootstrap process. Because it doesn't look like a bug
in anything guarded by --harmony-arrays directly, I'd suggest
shipping the flag and disabling the test on the architectures
where it's been observed to fail. It's already disabled on arm64
and this patch disables it on mips64 as well.

BUG=v8:4200
LOG=N
R=adamk

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

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

Port 7a63bf77

Original commit message:
This makes new.target work in [[Call]] and [[Construct]] of ordinary
functions.

We achieve this by introducing a new construct stub for functions that
uses the new.target variable. The construct stub pushes the original
constructor just above the receiver in the construct frame.

R=arv@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

BUG=v8:3887
LOG=N
R=caitpotter88@gmail.com, adamk@chromium.org

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

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

This makes new.target work in [[Call]] and [[Construct]] of ordinary
functions.

We achieve this by introducing a new construct stub for functions that
uses the new.target variable. The construct stub pushes the original
constructor just above the receiver in the construct frame.

BUG=v8:3887
LOG=N
R=adamk@chromium.org, dslomov@chromium.org

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

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

We were calling the setter for Object.prototype.promise if it existed
when calling PromiseAll.

BUG=v9:4232
LOG=N
R=rossberg@chromium.org, adamk@chromium.org

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

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

zlib is broken for mips after 35eb3a02.

We're still working on a fix. Skip test for now, so the bots cycle green.

BUG=

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

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

BUG=chromium:505228
LOG=Y

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

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

Only this way we can precisely determine how to allocate let variables
inside the scope.

R=rossberg@chromium.org
BUG=v8:4255
LOG=N

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

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

Enable skipped test-api/RequestInterruptTestWith* after:
https://codereview.chromium.org/1220443002/

TEST=
BUG=

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

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

Separated core greedy allocator concepts, exposing the APIs we would want to continue working with. In particular, this change completely reworks CoalescedLiveRanges to reflect the fact that we expect more than one possible conflict, scrapping the initial design of the structure. Since this is a critical part of the design, this change may be thought of as a full rewrite of the algorithm.

Reduced all heuristics to just 2 essential ones: split "somewhere", which we'll still need when all other heuristics fail; and spill.

Introduced a simple primitive for splitting - at GapPosition::START. The goal is to use such primitives to quickly and reliably author heuristics.

I expected this primitive to "just work" for any arbitrary instruction index within a live range - e.g. its middle. That's not the case, it seems to upset execution in certain scenarios. Restricting to either before/after use positions seems to work. I'm still investigating what the source of failures is in the case of "arbitrary instruction in the range" case.

I intended to document the rationale and prove the soundness of always using START for splits, but I will postpone to after this last remaining issue is resolved.

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

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

This one occurs when Function.prototype.toString is overridden to return a
non-string.

BUG=chromium:504729
R=mstarzinger@chromium.org
LOG=n

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

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

Dumb typo introduced in refs/heads/master@{#29306}. I thought I was turning on
report_exceptions in Shell::ExecuteString, but instead I turned on print_result
(which assumes an interactive debugger and a HandleScope for the
utility_context_).

BUG=chromium:504727,chromium:504728
R=mstarzinger@chromium.org
LOG=n

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

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

The android_* configs were never real v8 target
architectures, only make targets. This doesn't make sense
with ninja anymore.

BUG=chromium:502176
LOG=n
NOTRY=true

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

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

BUG=chromium:505367
LOG=N

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

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

RegExpCompileEvent acquieres mutex from Log class during MessageBuilder creation. LogRegExpSource, called from RegExpCompileEvent creates another MessageBuilder object which also acquires the same mutex. This mutex is not recursive, so during second acquirement, assertion fail is happening. Solution: LogRegExpSource should use the same MessageBuilder object as RegExpCompileEvent.

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

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

BUG=505228
LOG=Y

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

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