Port 978ad03b

Original commit message:
    Fix and re-enable the flexible representation for Math.floor (which is used to
    implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
    return double results instead of int32, and therefore allows values outside
    the int32 range, especially -0 is now a valid result, which doesn't deopt.

    Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
    extension.

    This addresses all the known deoptimization loops related to Math.round
    in the Kraken benchmark suite, and seems to also address most of the
    deoptimization loops related to Math.floor in the Oort Online benchmark.

    Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
    optimization that caused the initial revert of the feature (for arm64 only
    back then).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:476477,v8:2890,v8:4059
LOG=n

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

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

Port ce1fe78d

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=chromium:585041
LOG=N

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

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

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}

Port f2a58593

Original commit message:
    Replace the uses with proper page flag lookups.

R=mlippautz@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:581412
LOG=N
TEST=mjsunit/allocation-site-info

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

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

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}

Port 1134688c

Original commit message:
    This roughly doubles performance for generic Array.prototype.push.

R=verwaest@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port acbb968d
Port 66e22b79

Original commit messages:
    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.

    Always generate lazy bailout points for tail calls because Debugger could still require them to inspect optimized frames.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:596473, v8:4698
LOG=N

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

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

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

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

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

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}

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}

Port 9dcd0857

Original commit message:
    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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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}

Port 22938040

Original commit message:
    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.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4698
LOG=N

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

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

Port 5912e0f0

Original commit message:
    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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port 2689548e

Original commit message:
    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.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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}

Port 55071954

Original commit message:
    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.

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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}

Port 0d59772b

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

R=jkummerow@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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}

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

Port 3ce9e808

Original commit message:
    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.

R=verwaest@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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}

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

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}

Port 6131ab1e

Original commit message:
    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.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4698
LOG=Y

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

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

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}

Port f48bf12f

Original commit message:
    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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:3650
LOG=n

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

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

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 motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.

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

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

This refactoring removes the dependency on the Token class from the
assembler.h header file, the utility function in question has nothing
to do with assembling in the first place.

R=bmeurer@chromium.org

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

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

No functional change.  This is prep for fixing test failures in wasm tests.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Change the CompilationInfo::IsCodePreAgingActive() predicate to CompilationInfo::GeneratePreagingPrologue() and handle the case of WASM functions, which should not be aged.

R=mstarzinger@chromium.org
BUG=

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

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