Add an extra paramter to disable scale on BaseWithIndexAndDisplacementMatcher.

R=bmeurer@chromium.org, epertoso@chromium.org, jarin@chromium.org, mstarzinger@chromium.org, mtrofin@chromium.org, titzer@chromium.org
BUG=

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

Adds TestResultScope and uses it to directly jump/fall through to the
correct branch in expressions used as branch conditions.
Should enable nicer TurboFan-graphs for easier control-flow
transformations in the future.

BUG=v8:4280
LOG=n

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

Removes Variable::is_possibly_eval() and instead stores whether
a call is possibly eval in the Call node's bitfield.

Also removes HandleDereferenceMode since it's no longer used.

BUG=v8:5203

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

R=jarin@chromium.org

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

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to ac24d974a70c8611d2837e183d6cf99f39fb0410

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

This includes unsigned integers (encoded as base-128 varints), signed integers
(ZigZag-encoded, then varint-encoded) and doubles (written in host byte order).

BUG=chromium:148757

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

Rolling v8/build to 4155375bddb65fe3d2dbc42ab0d64c4d72527165

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 9d440c96636c5a41ce3e40f1924fe41dd2694f51

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

Rolling v8/build to 45574dce74fca42e485fbc5cd78bd24bcfeb905f

Rolling v8/buildtools to adb8bf4e8fc92aa1717bf151b862d58e6f27c4f2

Rolling v8/tools/clang to 6d377a47e9c668c7550d17a7d4e6ba9f5931703a

Rolling v8/tools/mb to c78da3f5bccc979b35907c4cbf937aa5187e41fa

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

No longer include the "async" keyword, or an async arrow function's single
identifier parameter as part of its inferred name.

BUG=v8:5281, v8:4483
R=adamk@chromium.org, littledan@chromium.org, marja@chromium.org

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

Throw 'Range Error: invalid string length' when the result of
case mapping is longer than the max string length (kMaxLength in
objects.h = 1 << 28 - 16).

This is for case mapping with ICU.

A new test (case-mapping-slow.js) is added with PASS,SLOW. It's
configured to skip unless arch=x64 and mode=release and not on
simulator.

This is a reattempt to land
 https://codereview.chromium.org/2236593002 that was reverted.

BUG=v8:5271
TEST=intl/general/case-mapping-slow.js with --icu_case_mapping

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

BUG=chromium:148757

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

The hand-written KeyedLoadIC_Megamorphic stub didn't care about JSArray
lengths, which made it lenient towards said lengths being wrong, but it
will soon fix that bug and thereby become more strict.

LiveEdit: factory->NewJSArray(capacity) doesn't set a length, so set it
manually.
RegExp: to avoid having to take care of array length updating in the
RegExpExecStub, just use a JSObject instead.

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

Revert of [interpreter] Inline ForInFilter stub. (patchset #1 id:1 of https://codereview.chromium.org/2220343002/ )

Reason for revert:
Speculative revert to possible performance regressions.

BUG=chromium:635826,chromium:635930

Original issue's description:
> [interpreter] Inline ForInFilter stub.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/2bf0b8c8ed5d0c93982c8c227e93622aceecea16
> Cr-Commit-Position: refs/heads/master@{#38420}

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

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

    Instead of loading 64 bits and shifting:

      ldr x0, [x1, #offset]
      asr x0, x0, #32

    directly load the interesting 32 bits and sign-extend:

      ldrsw x0, [x1, #offset+4]

BUG=

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

R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5265

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

This adds a shortcut to the compilation pipeline that makes sure we are
not regenerating bytecode when it has been preserved from a previous
request. This can happen when code flushing removes baseline code,
thereby clearing the entry trampoline but leaving bytecode intact.

R=yangguo@chromium.org
BUG=v8:5265

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

kudos to marja@ for finding this

BUG=v8:5209

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

Also, re-enables the use of the type feedback in BytecodeGraphBuilder.

BUG=v8:5273
LOG=N

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

This removes some compiler internals as well as some JavaScript specific
helper from the CodeAssembler, by either hiding or moving the support
into the CodeStubAssembler.

R=bmeurer@chromium.org

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

This should be faster and should give the same result.

BUG=v8:5203

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

Properly deoptimize if the left hand side of a CheckedInt32Mod is
negative and the result of the operation is zero.

R=jarin@chromium.org
BUG=v8:5286

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

With --ignition-preserve-bytecode, we don't have the guarantee that
SharedFunctionInfo::abstract_code() returns the code we deopt to.

R=mstarzinger@chromium.org
BUG=v8:5265

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

Revert of "[heap] Switch to 500k pages" (patchset #11 id:220001 of https://codereview.chromium.org/2232653003/ )

Reason for revert:
Breaks benchmark with --turbo on avx2

https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20avx2/builds/9895

Original issue's description:
> Reland of "[heap] Switch to 500k pages"
>
> Decrease regular heap object size to 400k. In a follow up, we can now get rid of
> the new space border page while keeping the 1M minimum new space size.
>
> BUG=chromium:636331
>
> This reverts commit 555c9619.
>
> Committed: https://crrev.com/20e2ea80e169e85c5b8231adc02901fb6c989609
> Cr-Commit-Position: refs/heads/master@{#38608}

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

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

BUG=

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

This bug was triggered by a very specific combination:

* A context-allocated variable at script scope.
* OSR optimization.
* A scheduled breakpoint, which triggers at stack checks.

Stack checks differ from other possible breakpoint locations in that
the context (among other things) may be in a register and not on the
stack, making it impossible to recover during deoptimization. The
frame_inspector then returns undefined when asked for the context.

In GetFrameDetails, handle this case by omitting all context-allocated
variables.

BUG=v8:5279

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

This test would have failed prior to 58524d6d.

R=verwaest@chromium.org

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

BUG=chromium:630386

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

Decrease regular heap object size to 400k. In a follow up, we can now get rid of
the new space border page while keeping the 1M minimum new space size.

BUG=chromium:636331

This reverts commit 555c9619.

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

R=mstarzinger@chromium.org
BUG=v8:5265

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

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

Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. (patchset #3 id:40001 of https://codereview.chromium.org/2229243003/ )

Reason for revert:
There is a data race in the initialization of the Isolate::random_number_generator()

Original issue's description:
> [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject.
>
> This CL splits CodeGenerator::GenerateCode into two new functions:
> AssembleCode and FinishCodeObject. AssembleCode does not access or
> modify the JS heap, which means that AssembleCode can be executed on
> background threads. FinishCodeObject allocates the generated code object
> on the JS heap and therefore has to be executed on the main thread.
>
> Implementation details:
> The GenerateCode function has been split just before out-of-line code is
> assembled. The reason is that code stubs may be generated when
> out-of-line code is assembled, which potentially allocates these code
> stubs on the heap.
>
> - Parts of initialization of the CodeGenerator has been moved from the
> constructor to an Initialize function so that we can instantiate an empty
> CodeGenerator object in PipelineData.
>
> R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2
> Cr-Commit-Position: refs/heads/master@{#38604}

TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@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/2240523003
Cr-Commit-Position: refs/heads/master@{#38605}

This CL splits CodeGenerator::GenerateCode into two new functions:
AssembleCode and FinishCodeObject. AssembleCode does not access or
modify the JS heap, which means that AssembleCode can be executed on
background threads. FinishCodeObject allocates the generated code object
on the JS heap and therefore has to be executed on the main thread.

Implementation details:
The GenerateCode function has been split just before out-of-line code is
assembled. The reason is that code stubs may be generated when
out-of-line code is assembled, which potentially allocates these code
stubs on the heap.

- Parts of initialization of the CodeGenerator has been moved from the
constructor to an Initialize function so that we can instantiate an empty
CodeGenerator object in PipelineData.

R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org

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

This adds a very first version of inlined Array.prototype.push into
TurboFan optimized code. The current inlined version has a potential
deopt loop, but it's unlikely that we hit it currently (Crankshaft
suffers from an even worse problem). Once we have a way to learn from
deopts we can fix this deopt loops.

It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.push, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.

BUG=v8:2229,v8:3952,v8:5267
R=jarin@chromium.org

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

R=mstarzinger@chromium.org
BUG=v8:5265

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

- Change sizes and counts to be size_t on the way.

R=hpayer@chromium.org
BUG=

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

BUG=v8:5193
NOTRY=true

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

BUG=

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

BUG=chromium:636368,chromium:635965,chromium:634900

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

A TransitionElementsKind operation is redundant if we already know that
the object has the target_map (independent of what the source_map might
be).

R=yangguo@chromium.org

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

Previously, we would both instrument the code, and add/remove
BreakPointInfo objects through BreakLocation. This is bad design and
unsuitable for having two different code kinds.

We would now add/remove BreakPointInfo objects, and use that as source
of truth when instrumenting the code. If we have both bytecode and FCG
code, we would simply apply these break points twice to either.

Notable changes:
- Removed many functionality from BreakLocation.
- Instrumentation (patching code for breaks) happens by applying break
  point info onto code.
- Instrumentation (code patching) is done by the BreakIterator. For
  bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's
  CodeBreakIterator.
- Changes to code instrumentation mostly involves clearing current
  instrumentation and then (re-)applying break points.
- DebugInfo can now reference both bytecode and FCG code.

R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5265

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