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

This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:

* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function

BUG=v8:5339

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

BUG=

Review-Url: https://chromiumcodereview.appspot.com/2403483002
Cr-Commit-Position: refs/heads/master@{#40423}

R=machenbach@chromium.org,titzer@chromium.org,bmeurer@chromium.org,jgruber@chromium.org
BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe

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

This is the next step to unify the Call/Construct feedback collection
and prepare it to be able to collect SharedFunctionInfo feedback. This
also reduces the CallICStub overhead quite a bit since we only need one
stub per mode (and tail call mode), not also one per call arity.

R=mvstanton@chromium.org
BUG=v8:2206
NOTRY=true

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

Adds support to collect allocation site feedback for Array function calls
to the call bytecode handler.

BUG=v8:4280, v8:4780
LOG=N

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

Collect type feedback in the bytecode handler for 'new' bytecode. The
earlier cl (https://codereview.chromium.org/2153433002/) was reverted
because that implementation did not collect allocation site feedback.
This regressed delta blue by an order of magnitude. This implementation
includes collection of allocation site feedback.

Reland of https://codereview.chromium.org/2190293003/ with a bug fix.

BUG=v8:4280, v8:4780
LOG=N

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

Introduce a dedicated MaybeGrowFastElements simplified operator, which
tries to grow a fast elements backing store for a given element that
should be added to an array/object. Use that to lower a growing keyed
store to a sequence of

 1) check index is a valid array index,
 2) check stored value,
 3) maybe grow elements backing store (and deoptimize if it would
    normalize), and
 4) store the actual element.

The actual growing is done by two dedicated GrowFastDoubleElements
and GrowFastSmiOrObjectElements builtins, which are very similar to
the GrowArrayElementsStub that is used by Crankshaft.

Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements
builtin, similar to the new growing builtins, so we don't need to
inline the store+write barrier for the elements into all optimized
code objects anymore.

Also fix a bug in the OperationTyper for NumberSilenceNaN, which was
triggered by this change.

BUG=v8:5272

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

This extends JSNativeContextSpecialization with support for stores to
fast object/smi element backing stores that are marked as copy-on-write.
In this case we first call the CopyFixedArray builtin to take a copy of
the elements backing store, and then store the new elements back to the
object, and finally perform the actual element store.

R=epertoso@chromium.org
BUG=v8:4470

Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6
Review-Url: https://codereview.chromium.org/2218703003
Cr-Original-Commit-Position: refs/heads/master@{#38370}
Cr-Commit-Position: refs/heads/master@{#38392}

Revert of [turbofan] Add support for copy-on-write element stores. (patchset #2 id:20001 of https://codereview.chromium.org/2218703003/ )

Reason for revert:
Breaks tree?

Original issue's description:
> [turbofan] Add support for copy-on-write element stores.
>
> This extends JSNativeContextSpecialization with support for stores to
> fast object/smi element backing stores that are marked as copy-on-write.
> In this case we first call the CopyFixedArray builtin to take a copy of
> the elements backing store, and then store the new elements back to the
> object, and finally perform the actual element store.
>
> R=epertoso@chromium.org
> BUG=v8:4470
>
> Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6
> Cr-Commit-Position: refs/heads/master@{#38370}

TBR=epertoso@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470

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

This extends JSNativeContextSpecialization with support for stores to
fast object/smi element backing stores that are marked as copy-on-write.
In this case we first call the CopyFixedArray builtin to take a copy of
the elements backing store, and then store the new elements back to the
object, and finally perform the actual element store.

R=epertoso@chromium.org
BUG=v8:4470

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

Revert of [Interpreter] Collect type feedback for 'new' in the bytecode handler (patchset #6 id:100001 of https://codereview.chromium.org/2190293003/ )

Reason for revert:
[Sheriff] Fails on nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/8403

Original issue's description:
> [Interpreter] Collect type feedback for 'new' in the bytecode handler
>
> Collect type feedback in the bytecode handler for 'new' bytecode. The
> earlier cl (https://codereview.chromium.org/2153433002/) was reverted
> because that implementation did not collect allocation site feedback.
> This regressed delta blue by an order of magnitude. This implementation
> includes collection of allocation site feedback.
>
> BUG=v8:4280, v8:4780
> LOG=N
>
> Committed: https://crrev.com/9d5e6129c4c7f9cbfe81a5fad2a470f219fe137c
> Cr-Commit-Position: refs/heads/master@{#38364}

TBR=bmeurer@chromium.org,rmcilroy@chromium.org,balazs.kilvady@imgtec.com,mythria@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4780

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

Collect type feedback in the bytecode handler for 'new' bytecode. The
earlier cl (https://codereview.chromium.org/2153433002/) was reverted
because that implementation did not collect allocation site feedback.
This regressed delta blue by an order of magnitude. This implementation
includes collection of allocation site feedback.

BUG=v8:4280, v8:4780
LOG=N

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

This will enable the interpreter to add a bytecode and use the stub.

BUG=v8:4280
LOG=n

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

This ports 9c59539f / r37803 to KeyedLoadICs.

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

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}

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}

Use the ForInFilterStub directly. Hence we will only jump to the runtime for
special receivers (instance_type <= LAST_SPECIAL_RECEIVER_TYPE) and for
converting element indices which are not in the string cache.

BUG=

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

Revert of [Interpreter] Collect type feedback for 'new' in the bytecode handler (patchset #6 id:100001 of https://codereview.chromium.org/2153433002/ )

Reason for revert:
This cl causes a large regression in octane (https://chromeperf.appspot.com/group_report?bug_id=629503). I have to investigate the reason before I can reland this.

Original issue's description:
> [Interpreter] Collect type feedback for 'new' in the bytecode handler
>
> Collect type feedback in the bytecode handler for 'new' bytecode. The
> current implementation does not collect allocation site feedback.
>
> BUG=v8:4280, v8:4780
> LOG=N
>
> Committed: https://crrev.com/1eadc76419b323fb2e55ae9953142f801704aa59
> Cr-Commit-Position: refs/heads/master@{#37862}

TBR=rmcilroy@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4780

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

Collect type feedback in the bytecode handler for 'new' bytecode. The
current implementation does not collect allocation site feedback.

BUG=v8:4280, v8:4780
LOG=N

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

This adds initial support for ToPrimitive in JavaScript w/o having to
call out to C++. This uses the newly introduced GetPropertyStub.

R=ishell@chromium.org

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

Collect type feedback in the call bytecode handler. The current
implementation only collects feedback for JS function objects. The other
objects and Array functions do not collect any feedback. They will be
marked Megamorphic.

BUG=v8:4280, v8:4780
LOG=N

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

Converts FastNewClosureStub from a Hydrogen to a TurboFan code stub.
The plan is to start using this in the Interpreter CreateClosure
bytecode handler (in a follow-up CL).

BUG=v8:4280

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

Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.

Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.

BUG=v8:3599,v8:5086,v8:5157

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

Adds support for intrinsics which can be called as stubs. Namely:
 - HasProperty
 - MathPow
 - NewObject
 - NumberToString
 - RegExpConstructResult
 - RegExpExec
 - Substring
 - ToString
 - ToName
 - ToLength
 - ToNumber
 - ToObject

Also adds interface descriptors for stub calls which have arguments
passed on the stack.

BUG=v8:4280
LOG=N

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

The former will handle loads of predeclared global variables (vars and
functions), lets, consts and undeclared variables. The latter will handle
named loads from explicit receiver. In addition, named loads does not
depend of the TypeofMode.

TypeofMode related cleanup will be done in the follow-up CL.

BUG=chromium:576312
LOG=Y
TBR=bmeurer@chromium.org

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

In Crankshaft, we would install special ICs that didn't need a vector and slot
in the MEGAMORPHIC case. This optimization limits our hand against future
improvements.

BUG=

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

The previous approach taken by FastNew[Sloppy,Strict,Rest]ArgumentsStub
looked at the function slot in order to skip stub frames
and find the JS frame. However, stub frames do not have a
function slot (in fact their fixed frame ends one slot
before the JS frame's function slot). Therefore, if this
location in the stub frame happens to have the function
object the create arguments stubs won't skip this frame
correctly.

Replace this approach with one where the stub is
specialized to either skip a frame if required (since
there will only ever be one extra frame on Ignition
the loop approach isn't necessary).

BUG=v8:4928
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg

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

This adds a new pass MemoryOptimizer that walks over the effect chain
from Start and lowers all Allocate, LoadField, StoreField, LoadElement,
and StoreElement nodes, trying to fold allocations into allocation
groups and eliminate write barriers on StoreField and StoreElement if
possible (i.e. if the object belongs to the current allocation group and
that group allocates in new space).

R=hpayer@chromium.org, jarin@chromium.org
BUG=v8:4931, chromium:580959
LOG=n

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

Code common with ObjectHasOwnProperty builtin was moved to CodeStubAssembler.

BUG=v8:2743
LOG=Y

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

Further refactor the pipeline to even run the first scheduler (part of
the effect control linearization) concurrently. This temporarily
disables most of the write barrier elimination, but we will get back to
that later.

Drive-by-fix: Remove the dead code from ChangeLowering, and stack
allocate the Typer in the pipeline. Also migrate the AllocateStub to a
native code builtin, so that we have the code object + a handle to it
available all the time.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
R=mstarzinger@chromium.org
BUG=v8:4969
LOG=n

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

Adds IncStub and DecStub TurboFan code stubs and hooks them up to the
interpreter's Inc and Dec bytecodes (which are used for count
operations, e.g. i++).

BUG=v8:4280
LOG=N

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

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

This avoids custom compilation of receiver handlers for api getters.

BUG=

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

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

Reland of (https://codereview.chromium.org/1891033002)

This is a much cleaner solution, which won't require nearly as much
architecture-specific code. Thanks bmeurer@!

BUG=v8:4614
LOG=y
TBR=bmeurer@chromium.org

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

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

Revert of [Atomics] Remove Atomics code stubs; use TF ops (patchset #6 id:100001 of https://codereview.chromium.org/1891033002/ )

Reason for revert:
[Sheriff] Breaks
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20ASAN%20mipsel%20-%20debug%20builder/builds/6121

Original issue's description:
> [Atomics] Remove Atomics code stubs; use TF ops
>
> This is a much cleaner solution, which won't require nearly as much
> architecture-specific code. Thanks bmeurer@!
>
> BUG=v8:4614
> LOG=y
> R=bmeurer@chromium.org,jarin@chromium.org
>
> Committed: https://crrev.com/6ff5881b1def45b35384572f61327e42563a89c3
> Cr-Commit-Position: refs/heads/master@{#35547}

TBR=bmeurer@chromium.org,jarin@chromium.org,rodolph.perfetta@gmail.com,binji@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4614

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

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

This is a much cleaner solution, which won't require nearly as much
architecture-specific code. Thanks bmeurer@!

BUG=v8:4614
LOG=y
R=bmeurer@chromium.org,jarin@chromium.org

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

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

Reland of (https://codereview.chromium.org/1617503003)

* New atomic code stubs for x64, ia32, arm, arm64
* Add convenience functions JumpIfNotValidSmiValue, JumpIfUintNotValidSmiValue
  to macro-assembler-ia32 (API based on x64 macro assembler)
* Remove runtime implementation of Atomics.load, the code stub should always be
  called instead
* Add new test to mjsunit atomics test; check that Smi values of different
  sizes are supported when possible, else fall back to HeapNumbers

These changes were needed to add another codestub:
* Bump kStubMajorKeyBits from 7 to 8
* Reduce ScriptContextFieldStub::kSlotIndexBits from 13 to 12

BUG=v8:4614
LOG=y
TBR=jarin@chromium.org,bmeurer@chromium.org,rodolph.perfetta@gmail.com,machenbach@chromium.org

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

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

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

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

Add the stubs for JavaScript's '<<', '>>' and '>>>' operators and lets Ignition make use of them in the respective bytecode handlers.

Committed: https://crrev.com/599369d6b8e1a5ccdca857def06eebcbacf47dd4
Cr-Commit-Position: refs/heads/master@{#35433}

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

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

Revert of [stubs] Introduce LeftShift, SignedRightShift and UnsignedRightShift stubs. (patchset #3 id:40001 of https://codereview.chromium.org/1881003002/ )

Reason for revert:
Needed to revert https://codereview.chromium.org/1617503003

Original issue's description:
> [stubs] Introduce LeftShift, SignedRightShift and UnsignedRightShift stubs.
>
> Add the stubs for JavaScript's '<<', '>>' and '>>>' operators and lets Ignition make use of them in the respective bytecode handlers.
>
> Committed: https://crrev.com/599369d6b8e1a5ccdca857def06eebcbacf47dd4
> Cr-Commit-Position: refs/heads/master@{#35433}

TBR=bmeurer@chromium.org,epertoso@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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