BUG=

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

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

BUG=chromium:585041
LOG=N

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

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

Now that we no longer compile stubs from JavaScript source, but have
other means of generating stubs using our optimizing compilers, we can
assume that scope analysis has happened whenever prologues are being
assembled.

R=bmeurer@chromium.org

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

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

This CL ensures that we build environments/frame states so that tail caller frame will never become topmost.

BUG=chromium:598998, v8:4698
LOG=N

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

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

Replace the uses with proper page flag lookups.

BUG=chromium:581412
LOG=N
TEST=mjsunit/allocation-site-info

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

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

Context is always available through deopt data, so there should be
no need to store the context back to the frame every time. (Turbofan
already does not store back to the frame.)

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

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

BUG=v8:4698
LOG=N
TBR=bmeurer@chromium.org

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

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

This roughly doubles performance for generic Array.prototype.push.

BUG=

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

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

... because Debugger could still require them to inspect optimized frames.

BUG=chromium:596473, v8:4698
LOG=N

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

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

Bounds check hoisting was known to be buggy and has never been turned on.
Since Crankshaft is deprecated, nobody is going to spend time fixing it,
so let's just get rid of it.

BUG=v8:4155,v8:4849
LOG=n
R=bmeurer@chromium.org

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

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

In case when F inlined normal call to G which tail calls H we should not write translation for G for the tail call site.
Otherwise we will see G in a stack trace inside H.

This CL also enables all existing tests related to ES6 tail call elimination and adds more combinations.

TBR=bmeurer@chromium.org
BUG=v8:4698
LOG=N

Committed: https://crrev.com/689980f7d4dfd4c29492f616d7b616b86ec9af91
Cr-Commit-Position: refs/heads/master@{#34830}

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

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

Revert of [crankshaft] Fixing ES6 tail call elimination. (patchset #7 id:200001 of https://codereview.chromium.org/1780043004/ )

Reason for revert:
[Sheriff] Leads to mac gc stress crashes:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/4975

Original issue's description:
> [crankshaft] Fixing ES6 tail call elimination.
>
> In case when F inlined normal call to G which tail calls H we should not write translation for G for the tail call site.
> Otherwise we will see G in a stack trace inside H.
>
> This CL also enables all existing tests related to ES6 tail call elimination.
>
> TBR=bmeurer@chromium.org
> BUG=v8:4698
> LOG=N
>
> Committed: https://crrev.com/689980f7d4dfd4c29492f616d7b616b86ec9af91
> Cr-Commit-Position: refs/heads/master@{#34830}

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

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

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

In case when F inlined normal call to G which tail calls H we should not write translation for G for the tail call site.
Otherwise we will see G in a stack trace inside H.

This CL also enables all existing tests related to ES6 tail call elimination.

TBR=bmeurer@chromium.org
BUG=v8:4698
LOG=N

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

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

This fix removes unnecessary nops from function prolog and seems to recover performance regression on some of SunSpider benchmarks.

TBR=bmeurer@chromium.org
BUG=chromium:531369
LOG=N

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

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

TBR=bmeurer@chromium.org
BUG=v8:4698
LOG=N

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

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

This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

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

Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.

This CL attempts to improve this by:

* Ensuring that there are only two fundamentally different
  types of frames, a "standard" frame and a "typed" frame.
  Standard frames, as before, contain both a context and
  function pointer. Typed frames contain only a minimum
  of a smi marker in the position immediately below the fp
  where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
  TurboFan JavaScript frames use the "standard" format. All
  other frames use the type frame format with an explicit
  marker.
* Typed frames can contain one or more values below the
  type marker. There is new magic macro machinery in
  frames.h that simplifies defining the offsets of these fields
  in typed frames.
* A new flag in the CallDescriptor enables specifying whether
  a frame is a standard frame or a typed frame. Secondary
  register location spilling is now only enabled for standard
  frames.
* A zillion places in the code have been updated to deal with
  the fact that most code stubs and internal frames use the
  typed frame format. This includes changes in the
  deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
  (CommonFrameConstants::kContextOrFrameTypeOffset
  and StandardFrameConstants::kFrameOffset are now used
  in its stead).

LOG=N

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

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

HInvokeFunction and HApplyArguments instructions now support tail calling.

Inlining of calls at tail position is not supported yet and therefore still disabled.

The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft.

TBR=bmeurer@chromium.org
BUG=v8:4698
LOG=N

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

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

Add StringLessThanStub, StringLessThanOrEqualStub, StringGreaterThanStub
and StringGreaterThanOrEqualStub, based on the CodeStubAssembler, and
hook them up with TurboFan (and Ignition). The stubs are currently
essentially comparable with the StringCompareStub, which is now
obsolete. We can later extend these stubs to cover more interesting
cases (i.e. two byte sequential string comparisons, etc.).

R=epertoso@chromium.org

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

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

These new stubs perform exactly the same job as the string equality case
for the CompareIC, but are platform independent and usable outside of
fullcodegen and Crankshaft. We use them in the StrictEqualStub and the
StrictNotEqualStub instead of falling back to the runtime immediately
for String comparisons, and we also use them in TurboFan to perform
String equality or inequality comparisons.

These stubs currently handle only internalized and one byte strings w/o
going to C++, but it should be easy to add support for more string cases
later, i.e. utilizing already flattened cons strings or comparing two
byte strings as well.

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

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

Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

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

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

Everything that HCallJSFunction does can be easily done using more general HInvokeFunction, so there's no need to have this dedicated instruction around.

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

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

Everything that HCallFunction does can be easily done using more general HCallWithDescriptor, so there's no need to have this dedicated instruction around.

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

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

Frame slots indexes numbers are used more consistently for
computation in both TurboFan and Crankshaft. Specifically,
Crankshaft now uses frame slot indexes in LChunk, removing
the need for some special-case maths when building the
deoptimization translation table.

LOG=N
R=mstarzinger@chromium.org

Committed: https://crrev.com/81423b84dbb2eaf7e1a57b0f6029fc8e643b4755
Cr-Commit-Position: refs/heads/master@{#34078}

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

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

Revert of More simplification and unification of frame handling (patchset #5 id:80001 of https://codereview.chromium.org/1702593002/ )

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

Original issue's description:
> More simplification and unification of frame handling
>
> Frame slots indexes numbers are used more consistently for
> computation in both TurboFan and Crankshaft. Specifically,
> Crankshaft now uses frame slot indexes in LChunk, removing
> the need for some special-case maths when building the
> deoptimization translation table.
>
> LOG=N
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/81423b84dbb2eaf7e1a57b0f6029fc8e643b4755
> Cr-Commit-Position: refs/heads/master@{#34078}

TBR=mstarzinger@chromium.org,jarin@chromium.org,danno@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/1708583002

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

Frame slots indexes numbers are used more consistently for
computation in both TurboFan and Crankshaft. Specifically,
Crankshaft now uses frame slot indexes in LChunk, removing
the need for some special-case maths when building the
deoptimization translation table.

LOG=N
R=mstarzinger@chromium.org

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

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

It's dead^Wa runtime call Jim!

R=jarin@chromium.org

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

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

Everything that HCallStub does can easily be done using the more general
HCallWithDescriptor, so there's no need to have this dedicated
instruction around.

R=jarin@chromium.org

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

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

R=rossberg@chromium.org,bmeurer@chromium.org,verwaest@chromium.org
BUG=v8:3956
LOG=n

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

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

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

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

for the special case where the same register is used as both left and
right input.

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

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

This CL also removes tail call support made so far from Crankshaft.

BUG=v8:4698
LOG=N

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

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

Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic

Marking as undetectable makes abstract equality of null, undefined, and
other undetectable objects easier. Supporting it in the generic compare
IC significantly speeds up dynamic comparison between those values and
JSReceivers by not falling back to the runtime.

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

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

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

By now only the default %TypedArray%.prototype.sort compare function
and the JS implementation of SameValueZero were still using the odd
%_IsMinusZero intrinsic, whose semantics both included a number check
(actually HeapNumber test) plus testing if the heap number stores the
special -0 value. In both cases we already know that we deal with
number so we can reduce it to a simple number test for -0, which can
be expressed via dividing 1 by that value and checking the sign of
the result. In case of the compare function, we can be even smarter
and work with the reciprocal values in case x and y are equal to 0
(although long term we should probably rewrite the fast case for
the typed array sorting function in C++ anyway, which will be way,
way faster than our handwritten callback-style, type-feedback
polluted JS implementation).

R=yangguo@chromium.org

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

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

The flag in question is a debug-only flag supported by full-codegen and
Crankshaft only. In it's current form there are some unresolved issues:
- The flag is defeated by inlining in Crankshaft.
- The flag is not supported by TurboFan.
- The flag is not supported by Ignition.

Instead of addressing the above issues and increasing maintenance cost
for all backends and also given the "slim" test coverage, this CL fully
removes the support from all backends.

R=bmeurer@chromium.org,jkummerow@chromium.org

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

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

String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:

if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
  /* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);

This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.

No observable change in behavior is intended.

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

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

This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.

Tail calling can be enabled by --harmony-tailcalls flag.

BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org

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

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

Cleanup %ForInPrepare runtime entry, and unify common logic with
%ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
a TupleType to properly type JSForInPrepare and its projections w/o
special hacks in the Typer. And fix %ForInNext and JSForInNext to be
consistent with fullcodegen again (after the proxy refactorings last
quarter).

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

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

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

There's no need to have HMapEnumLength as a dedicated instruction,
as it can be expressed using a HLoadNamedField plus an HBitwiseAnd
operation.

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

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

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

The PrepareId bailout location was used incorrectly in Crankshaft and,
as it turns out, is not required anyway (once you do it right). Also
there was some premature optimization going on with the CheckEnumCache
(trying to load null from roots only once), plus we can be smarter about
the null/undefined check anyway.

The idea behind this changes is to prepare unification of the two
different ForInPrepare implementations that we now have, with the end
result being that we only use the new implementation that was recently
added for the interpreter.

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

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

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