R=jarin@chromium.org
BUG=chromium:465663
LOG=n

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

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

R=mstarzinger@chromium.org
BUG=chromium:462775
LOG=Y

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

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

BUG=

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

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

Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.

Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.

Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.

BUG=v8:3953
LOG=n
R=yangguo@chromium.org,svenpanne@chromium.org

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

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

Context specialization enables inlining (at least currently it is the
only enabler for inlining), but inlining enables more possibilities for
context specialization. So we really need to run them together.

This is especially important with the "module based builtins" that we're
working towards.

BUG=v8:3952
LOG=n

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

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

since the old style weakness is slated for removal, we might as well reuse the name to limit confusion.  additionally I simplified the callback type to a enum to either get internal field values or not

this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused.

R=jochen@chromium.org, erikcorry@chromium.org

BUG=

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

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

BUG=

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

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

BUG=chromium:464657
LOG=n
TBR=jochen@chromium.org

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

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

BUG=chromium:464657
LOG=n

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

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

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}