Note that this is done only for consistency at this point in time.
The change should probably have been in
https://codereview.chromium.org/984963002/ already.

BUG=v8:3947
LOG=n

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

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

R=hpayer@chromium.org
LOG=n
BUG=none

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

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

Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).

BUG=

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

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

R=dslomov@chromium.org
BUG=

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

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

The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.

We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.

The test was reworked so it tests identical functions against different reasons.

BUG=chromium:452067
LOG=n

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

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

Methods can refer to the class name.

BUG=v8:3927
LOG=N

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

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

R=mstarzinger@chromium.org

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

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

After establishing the invariant that the store buffer always has valid slots after marking, the store buffer integrity check is not needed anymore.

BUG=454157
LOG=n

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

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

R=jkummerow@chromium.org

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

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

This slightly hacky change provides lazy deopt points for to-number conversions in binops: When we deopt from a to-number conversion, we create a frame state with the already-converted value(s) so that we do not repeat the side effect of the conversion.

Embenchen numbers are below. It is not quite clear what happened to fasta - the hot code looks nearly identical.

Current: EmbenchenBox2d(RunTime): 12746 ms.
d8-master: EmbenchenBox2d(RunTime): 13861 ms.
----------- bullet.js
Current: EmbenchenBullet(RunTime): 17680 ms.
d8-master: EmbenchenBullet(RunTime): 19170 ms.
----------- copy.js
Current: EmbenchenCopy(RunTime): 4939 ms.
d8-master: EmbenchenCopy(RunTime): 4943 ms.
----------- corrections.js
Current: EmbenchenCorrections(RunTime): 6639 ms.
d8-master: EmbenchenCorrections(RunTime): 6728 ms.
----------- fannkuch.js
Current: EmbenchenFannkuch(RunTime): 4630 ms.
d8-master: EmbenchenFannkuch(RunTime): 4872 ms.
----------- fasta.js
Current: EmbenchenFasta(RunTime): 10209 ms.
d8-master: EmbenchenFasta(RunTime): 9673 ms.
----------- lua_binarytrees.js
Current: EmbenchenLuaBinaryTrees(RunTime): 12936 ms.
d8-master: EmbenchenLuaBinaryTrees(RunTime): 15529 ms.
----------- memops.js
Current: EmbenchenMemOps(RunTime): 7357 ms.
d8-master: EmbenchenMemOps(RunTime): 7340 ms.
----------- primes.js
Current: EmbenchenPrimes(RunTime): 7530 ms.
d8-master: EmbenchenPrimes(RunTime): 7457 ms.
----------- skinning.js
Current: EmbenchenSkinning(RunTime): 15832 ms.
d8-master: EmbenchenSkinning(RunTime): 15630 ms.
----------- zlib.js
Current: EmbenchenZLib(RunTime): 11176 ms.
d8-master: EmbenchenZLib(RunTime): 11324 ms.

BUG=

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

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

This makes sure only the %_DeoptimizeNow intrinsic is inlined, and
not the %DeoptimizeNow one. It hence re-establishes the invariant
that JSIntrinsicLowering only deals with inline intrinsics.

R=jarin@chromium.org
TEST=mjsunit/compiler/eager-deopt-simple

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

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

The JSInliner used to load the context from the JSFunction node at
runtime, which introduced a HeapConstant (because we had to materialize
the JSFunction after context specialization) and a LoadField operation,
independent whether the inlinee actually uses the context. This is
rather cumbersome currently, and therefore this is now changed to just
embed the context constant instead. Once we do inlining based on
SharedFunctionInfo rather than JSFunction, we should reconsider this
decision and come up with a proper heuristic.

BUG=v8:3952
LOG=n
R=mstarzinger@chromium.org

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

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

The store buffer can contain stale store buffer entries, i.e., slot in dead objects pointing to new space objects. These slots are treaded as live slots which cause problems with non-pointer fields and makes concurrent sweeping complicated. Removing these pointers from the store buffer before it is used makes life easier.

BUG=

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

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

Revert of Store the next serial number in the function cache rather than in the isolate.Don't overwrite existi (patchset #4 id:60001 of https://codereview.chromium.org/988693003/)

Reason for revert:
This doesn't do what it's supposed to do. The problem seems to lie on the blink side, people aren't reusing their FunctionTemplates (or creating them when not necessary).

Original issue's description:
> Don't overwrite existing serial numbers on the function template, otherwise instantiating the function for a new context causes the serial number to bump.
>
> Committed: https://crrev.com/1e638c3610ec6938e5fb16c42018642195782fb2
> Cr-Commit-Position: refs/heads/master@{#27048}

TBR=yangguo@chromium.org,dcarney@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

BUG=

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

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

Avoid loading the stack pointer and the stack limit into allocatable
registers first, but generate a cmp rsp,[limit] instead.

R=dcarney@chromium.org

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

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

BUG=chromium:460937
R=ishell@chromium.org
LOG=n

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

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

Revert of Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer. (patchset #4 id:230001 of https://codereview.chromium.org/957273002/)

Reason for revert:
It caused a lot of Canary crashes.

Original issue's description:
> Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer.
>
> The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297
> LOG=Y
>
> Committed: https://crrev.com/9633ebabd405c264d33f603f8798c31f59418dcd
> Cr-Commit-Position: refs/heads/master@{#27054}

TBR=verwaest@chromium.org,hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297

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

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

Include what you use, and move implementation details to .cc file.

R=svenpanne@chromium.org

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

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

BUG=
R=svenpanne@chromium.org

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

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

BUG=
R=bmeurer@chromium.org

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

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

We mark certain builtins for inlining, and those should always be
inlined into optimized code (CrankShaft already handles it this way), so
we should support that in TurboFan as well. Currently this mainly
affects a certain set of Math functions, but once have the basics in
place we can extend this to any kind of builtin/code stub/accessor.

This adds a new flag --turbo_builtin_inlining (enabled by default), that
forces the inliner to always inline builtins marked for inlining, but
does not affect inlining of other functions (this is still controlled by
the --turbo-inlining flag).

BUG=v8:3952
LOG=n
R=jarin@chromium.org

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

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

This is currently the cleanest approach to avoid the useless stack check
during inlining. We might be able to just remove the useless stack
checks later when we have a phase that also takes care of removing
redundant stack checks on loop back edges (which we do not generate
currently).

On the other hand, the flag introduced here might be useful when
building code stubs/builtins/dom stubs using JS based DSL, because you
certainly don't want a JS-level stack check in a code stub.

R=jarin@chromium.org
BUG=v8:3952
LOG=n

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

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

Loading the coefficients from a the constants typed array is currently
blocking inlining MathSin and MathCos into TurboFan generated code,
because there is no type feedback and hence TurboFan has to generate a
LOAD_IC for every coefficient.

R=yanggou@chromium.org
BUG=v8:3952
LOG=n

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

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

The key idea here is that the stack check should be explicit, such that
we can eliminate unnecessary stack checks after graph building and
potentially inlining.

R=mstarzinger@chromium.org

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

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

BUG=
R=jkummerow@chromium.org

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

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

The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.

BUG=chromium:454297
LOG=Y

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

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

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

Revert of Revert of Revert of Turn on job based recompilation (patchset #1 id:1 of https://codereview.chromium.org/955723002/)

Reason for revert:
Breaks Octane on Arm64 running on Chrome.

BUG=464538

Original issue's description:
> Revert of Revert of Turn on job based recompilation (patchset #1 id:1 of https://codereview.chromium.org/937263004/)
>
> Reason for revert:
> reland
>
> Original issue's description:
> > Revert of Turn on job based recompilation (patchset #1 id:1 of https://codereview.chromium.org/935243003/)
> >
> > Reason for revert:
> > waterfall disagrees
> >
> > Original issue's description:
> > > Turn on job based recompilation
> > >
> > > BUG=v8:3608
> > > R=yangguo@chromium.org
> > > LOG=y
> > >
> > > Committed: https://crrev.com/4ae82f64b09cdc0182cee3a5cc619a9117ac5fbc
> > > Cr-Commit-Position: refs/heads/master@{#26826}
> >
> > TBR=yangguo@chromium.org
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=v8:3608
> >
> > Committed: https://crrev.com/35cc692aecdea54fb07479b8d7b71059851e07e8
> > Cr-Commit-Position: refs/heads/master@{#26827}
>
> TBR=yangguo@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:3608
>
> Committed: https://crrev.com/3735a0851a9e2726f8b50a46a3bc770992328264
> Cr-Commit-Position: refs/heads/master@{#26829}

TBR=yangguo@chromium.org,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3608

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

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

BUG=
LOG=N
R=arv@chromium.org

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

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

TEST=
BUG=

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

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

R=dcarney@chromium.org

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

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

Don't overwrite existing serial numbers on the function template, otherwise instantiating the function for a new context causes the serial number to bump.

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

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

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

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

Now the three intrinsic lists only differ in their compiler
support. Unifying the lists and making the logic what is supported in
which compiler local to the compilers themselves is handled in a
follow-up CL.

BUG=v8:3947
LOG=n

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

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

R=ulan@chromium.org

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

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

Original issue: https://codereview.chromium.org/980573002/

Simple transitions are now stored in a map's "transitions" field (as a WeakCell wrapping the target map); full TransitionArrays are used when that's not sufficient.
To encapsulate these storage format implementation details, functions for manipulating and querying transitions have been refactored to be static functions on the TransitionArray class, and take maps as inputs.

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

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

This involved renaming apart a few more intrinsics. In the long run,
we want to clean up redundant intrinsics which just delegate.

BUG=v8:3947
LOG=n

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

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

This makes now the same simplification as the chromium
release scripts do. For creating branch B from a gnumbd'ed
(aka real) commit X do:
1. Branch Y off the real X
2. Set refs/pending/heads/B to Y
3. Set refs/pending-tags/B to X
4. Set refs/heads/B to X

The old algorithm tried to branch off the pending
correspondent of X. That commit was determined by comparing
tree objects of the real X and commits on pending.
Unfortunately, multiple commits on one branch can refer to
the same tree object, e.g., for commits P, Q, R with R being
the revert of Q, P and R refer to the same tree object.

TBR=tandrii@chromium.org
NOTRY=true
TEST=./script_test.py
TEST=tools/release/create_release.py -a me -r you --dry-run

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

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

BUG=chromium:463028
LOG=n
R=bmeurer@chromium.org

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

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