Do not take the fast path for Array.prototype.keys() if the array length is not
guaranteed to be an Smi.

BUG=660925, v8:5388
R=bmeurer@chromium.org, mstarzinger@chromium.org

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

This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
 - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
 - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().

If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.

All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.

At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.

I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.

The following additional changes were necessary:
 - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
 - The class HPositionInfo was effectively dead code and is now removed.
 - SourcePosition has new printing and information facilities, including computing a full inlining stack.
 - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
 - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
 - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
 - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).

BUG=v8:5432

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

BUG=v8:5388
R=bmeurer@chromium.org
NOTRY=true

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

CodeAssembler::CallRuntime() with 5 arguments was declared but
not implemented.

BUG=

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

BUG=chromium:652721

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

In captured stack traces, all lines and columns must be 1-based.
Even though this makes things a bit ugly, we have to comply also for
wasm locations, where line and column encode function index and byte
offset (both are originally 0-based).

If we don't comply, the frontend might complain, as e.g. DevTools does.

BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.org
CC=titzer@chromium.org

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

Adds a protector cell to prevent inlining (which will likely lead to deopt
loops) when a JSArrayIterator's array transitions from a fast JSArray to a
slow JSArray (such as, when the array is touched during iteration in a way
which triggers a map transition).

Also adds TODO comments relating to the spec update proposed by Dan at
https://github.com/tc39/ecma262/pull/724

BUG=v8:5388
R=bmeurer@chromium.org, mstarzinger@chromium.org
TBR=hpayer@chromium.org, ulan@chromium.org

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

BUG=

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

BUG=v8:5619,chromium:664490

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

Using indices rather than pointers to probe the hashmap lets us
unconditionally mask the index to ensure it wraps around, rather than
branching on the pointer value. This produces slightly more optimal
code.

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

R=jgruber@chromium.org
BUG=

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

This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL
or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime
call to find the callee and possibly update the receiver with the with-object.
This means that eval calls out of 'with' blocks can now just do a normal
LdaLookupGlobalSlot operation, which can check the context chain for eval
extentions and fast-path the lookup if none exist.

BUG=661556

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

Revert of [ast] Simplify FetchFreeVariables. (patchset #1 id:1 of https://codereview.chromium.org/2491373004/ )

Reason for revert:
It's probably needed after all but we're lacking tests.

Original issue's description:
> [ast] Simplify FetchFreeVariables.
>
> This CL removes the ParseInfo argument from FetchFreeVariables, since it seems
> to have become unnecessary.
>
> R=verwaest@chromium.org
> BUG=

TBR=verwaest@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

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

This fixes the bogus {Word32Equal} comparison in the ToString builtin
implementing Object.prototype.toString to be a pointer-size {WordEqual}
comparison instead. Comparing just the lower half-word is insufficient
on 64-bit architectures.

R=jgruber@chromium.org
TEST=mjsunit/regress/regress-crbug-664506
BUG=chromium:664506

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

This replaces LOOKUP_SLOT_CALL with WITH_CALL, and relies on regular lookup-slot handling in variable load to support other lookup slots (variables resolved in the context of sloppy eval). This allows optimizations for such variable loads to kick in for calls as well. We only need special handling for function calls in the context of with, since it changes the receiver of the call from undefined/global to the with-object.

This currently doesn't yet make it work for the direct eval call itself, since the POSSIBLY_EVAL_CALL flag is also used to deal with direct eval later.

BUG=

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

Revert of [turbofan] Fix deoptimization of boolean bit constants. (patchset #1 id:1 of https://codereview.chromium.org/2495243002/ )

Reason for revert:
Seems to break GC stress.

Original issue's description:
> [turbofan] Fix deoptimization of boolean bit constants.
>
> BUG=chromium:664490

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

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

When constant-folding S[K], make sure to return a String, and not the
character code as Number.

BUG=chromium:664942
R=yangguo@chromium.org

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

Revert of MIPS: Optimize load/store with large offset (patchset #1 id:1 of https://codereview.chromium.org/2486283003/ )

Reason for revert:
Breaks CQ trybots now, i.e. https://build.chromium.org/p/tryserver.v8/builders/v8_linux_mipsel_compile_rel/builds/24703/steps/compile%20with%20ninja/logs/stdio

Original issue's description:
> MIPS: Optimize load/store with large offset
>
> Currently, we are using the following sequence for load/store with large offset (offset > 16b):
>
>     lui at, 0x1234
>     ori at, at, 0x5678
>     add at, s0, at
>     lw  a0, 0(at)
>
> This sequence can be optimized in the following way:
>
>     lui at, 0x1234
>     add at, s0, at
>     lw  a0, 0x5678(at)
>
> BUG=

TBR=ivica.bogosavljevic@imgtec.com,miran.karic@imgtec.com,v8-mips-ports@googlegroups.com,dusan.simicic@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

BUG=v8:5614

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

This helps if the polymorhpic case has other maps with fast accesses.

In box2d (with high number of iterations and warm-up), we spend about 2.7% of running time in StoreIC; after this change it is only 0.2%.

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

We are removing use of the debugger context. When the debugger triggers
compilation, we may not have a context from which to create a JSArray.

R=ishell@chromium.org
BUG=chromium:664577

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

In component build, unittests did not link with icu libraries, which
caused errors. By adding icu libraries to dependencies unittests links
correctly.

BUG=
TEST=unittests/*

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

R=mstarzinger@chromium.org

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

Currently, we are using the following sequence for load/store with large offset (offset > 16b):

    lui at, 0x1234
    ori at, at, 0x5678
    add at, s0, at
    lw  a0, 0(at)

This sequence can be optimized in the following way:

    lui at, 0x1234
    add at, s0, at
    lw  a0, 0x5678(at)

BUG=

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

R=mlippautz@chromium.org

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

BUG=chromium:664490

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

BUG=chromium:664411

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

Changes include:
 - Adding V8_EXPORT macro for SnapshotCreator
 - Removing outdated DCHECKs.
 - Allow nullptr as external reference. This required a...
 - Refactoring of hashmaps used by the serializer.
 - Remove external references for counters. These are not used
   anywhere for isolates that are being serialized.
 - Put template infos into the partial snapshot cache.
 - Remove unnecessary presubmit check for external references.
   mksnapshot crashes if external references are missing.

R=jochen@chromium.org, vogelheim@chromium.org
BUG=chromium:617892

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

TestBit sets cr0 therefore need to pass that to the
branch instruction.
This got exposed with testcase added in CL
https://codereview.chromium.org/2497573003/

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

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

Port 1915762c

Original commit message:

    These JavaScript operators were special hacks to ensure that we always
    operate on Smis for the magic for-in index variable, but this never
    really worked in the OSR case, because the OsrValue for the index
    variable didn't have the proper information (that we have for the
    JSForInPrepare in the non-OSR case).

    Now that we have loop induction variable analysis and binary operation
    hints, we can just use JSLessThan and JSAdd instead with appropriate
    Smi hints, which handle the OSR case by inserting Smi checks (that are
    always true). Thanks to OSR deconstruction and loop peeling these Smi
    checks will be hoisted so they don't hurt the OSR case too much.

    Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
    we have to lower it to JSLessThan to get the loop induction variable
    goodness.

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

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

BUG=v8:5561

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

Several weeks have now passed since it was deprecated; Chromium does not
call it.

BUG=chromium:148757

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

That way we don't have to update the perf tests whenever the exact
configuration changes.

R=mvstanton@chromium.org,hablich@chromium.org,danno@chromium.org
BUG=

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

BUG=chromium:148757

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

BUG=v8:5051
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

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

- Creates a new promise-utils.{h, cc} which refactors out the
logic to create resolving functions. This is shared between the
runtime functions and builtins.

- Changes PromiseResolveThenableJobInfo to store the context
since we no longer create the resolving functions in JS.

- Changes EnqueuPromiseResolveThenableJob to take in the promise and
  not the callbacks.

BUG=v8:5343

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

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

- Adds VmovExtended, VswpExtended methods to MacroAssembler. These methods
use only VFP registers to perform s-register moves.

LOG=N
BUG=v8:4124

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

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

Previous: https://codereview.chromium.org/2491773006

BUG=v8:5512

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