R=jgruber@chromium.org
BUG=v8:5902

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

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

R=titzer@chromium.org

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

This adds helper stubs for RegExp split and replace operations, called directly
by both RegExpPrototype{Replace,Split} and StringPrototype{Replace,Split}.

BUG=

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

This runs the existing checkpoint elimination during the "inlining"
optimization phase. It will eliminate redundant checkpoint nodes and
hence reduce graph size earlier. After this change the reducer in
question runs during {InliningPhase} as well as {TypedLoweringPhase}.

R=bmeurer@chromium.org

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

Apparently it happens quite easily that different NaNs are produced in
the interpreter than in the execution of the compiled code. This
non-determinism caused problems for the fuzzer which compares the
equality of the results of the interpreter and the compiled code.

I decided therefore to refactor the detection of non-determinism in the
interpreter. Instead of tracking whether potentially non-deterministic
NaNs were produced, I track now whether potentially non-deterministic
NaNs could have been observed. The only way the NaN non-determinism can
be observed is by observing the non-deterministic bit pattern of the
NaN. AFAICT the only way to observe the bit pattern is with a
I(32|64)_REINTERPRET_F(32|64) instruction or with a F(32|64)_STORE
followed by a load. Therefore I flag an execution as potentially
non-deterministic when either a NaN is reinterpreted to an int, or when
a NaN is stored to memory.

R=titzer@chromium.org, eholk@chromium.org
BUG=682180

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

R=jarin@chromium.org

BUG=

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

The wasm module we generate for the test case actually has an initial
memory size of 16. In the mjsunit test we generate, however, we set the
initial memory size to 32. This CL changes the initial memory size in
the mjsunit test now to 16.

R=eholk@chromium.org

Change-Id: I5d3a30a97c3b0ba3105a8cf17d4c088a8fb9c8b7
Reviewed-on: https://chromium-review.googlesource.com/436544
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42915}

By now the effect-control linearizer correctly determines the dominating
checkpoint, even for cases that contain effect-flow. We can elide the
temporary checkpoints during lowering of property loads and stores that
involve a sequence of map-checks.

R=bmeurer@chromium.org

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

BUG=v8:5516
R=vogelheim@chromium.org

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

Revert of [profiler] Fix attribution for the top-most interpreted frame. (patchset #3 id:40001 of https://codereview.chromium.org/2667253004/ )

Reason for revert:
Flaky crashes on mac asan:
https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/10739

Original issue's description:
> [profiler] Fix attribution for the top-most interpreted frame.
>
> Before this change, we attributed samples for the top-most interpreter frame to the second-topmost frame if we were in a bytecode handler with elided frame. With this change we try to detect that we are in a handler without a frame. If we are, we do not drop the topmost frame.
>
> For example, consider the program
>
> function inner() {
>   var s = 0;
>   for (var i = 0; i < 100000; i++) {
>     s += i * i;
>   }
>   return s;
> }
>
> function trivial() {
>   return inner();
> }
>
> for (var i = 0; i < 2000; i++) {
>   trivial();
> }
>
>
> Before this change, d8 --prof --ignition --nocrankshaft and linux-tick-processor would produce:
>
>   [JavaScript]:
>    ticks  total  nonlib   name
>    4885   83.4%   83.5%  Function: ~trivial a.js:15:17
>     759   13.0%   13.0%  Function: ~inner a.js:7:15
>
> After this change, we get
>
>  [JavaScript]:
>    ticks  total  nonlib   name
>    5486   95.9%   96.2%  Function: ~inner a.js:7:15
>       4    0.1%    0.1%  Function: ~trivial a.js:15:17
>
> Review-Url: https://codereview.chromium.org/2667253004
> Cr-Commit-Position: refs/heads/master@{#42894}
> Committed: https://chromium.googlesource.com/v8/v8/+/d07f6540c1f9628ed2ba1fa6507c90db07ccc5f5

TBR=bmeurer@chromium.org,jarin@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/2670843005
Cr-Commit-Position: refs/heads/master@{#42912}

Simulator trace will display content of target floating point registers.
Content of FP registers is displayed in hexadecimal form which is
followed with float or/and double interpretation.
Also, with this implementation will be displayed contents of general
purpose registers (GPRs). Hexadecimal form is followed with signed
and unsigned integer interpretation (32-bit or/and 64-bit).

TEST=
BUG=

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

This flag is true when compiled script is ES6 module.

BUG=v8:1569
R=dgozman@chromium.org,adamk@chromium.org

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

Turns out is_hidden is not the right condition for "scope should be present in
the preparse data". For now, replaced it with "is hidden leaf scope" (i.e.,
doesn't contain any non-hidden scopes). That's probably not the right condition
either; will be fixed once there's more data to decide what the right condition
is.

BUG=v8:5516
R=vogelheim@chromium.org

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

The extras utils object will no longer be needed after
bootstrapping, and can be cleared.

R=jochen@chromium.org

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

V8DebuggerAgentImpl::m_skipAllPaused is moved to V8Debugger.
V8DebuggerAgentImpl::didPaused doesn't return shouldBreak flag and called only when break is required and stack trace presented.
V8DebuggerAgentImpl doesn't store paused context.
Logic of conversion step-next at return into step-in is moved to debug.cc.

BUG=none
R=dgozman@chromium.org,yangguo@chromium.org

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

BUG=

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7a418db..d4321a9

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/fc2f450..53604dd

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/960cc3e..88069f4

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

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

R=rossberg@chromium.org, bradnelson@chromium.org
BUG=chromium:682659

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

- and removed ":" from the output of console.count without argument.

BUG=none
R=luoe@chromium.org,alph@chromium.org

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

R=titzer@chromium.org

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

We don't track concurrent recompilation/optimization in RCS, disabling it will
give us a better idea of the performance of our compilers.

Change-Id: I8138b09d5f112914f7c7929e9ece6f543423fd03
Reviewed-on: https://chromium-review.googlesource.com/436404Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42901}

BUG=v8:5911

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

BUG=v8:5516
R=vogelheim@chromium.org

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

Port eef855a1

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

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

R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com
BUG=

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

Port d68dfe86

Original Commit Message:

    Port the Call feedback machinery from the interpreter to the CallICStub
    as second step to unify the feedback collection. This removes a lot of
    hand-written native code, and makes the runtime miss handler obsolete.
    The next step will be to use the CallICStub from the interpreter as
    well.

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

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

And fixed gcc compilation.

BUG=none
R=alph@chromium.org,dgozman@chromium.org

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

Before this change, we attributed samples for the top-most interpreter frame to the second-topmost frame if we were in a bytecode handler with elided frame. With this change we try to detect that we are in a handler without a frame. If we are, we do not drop the topmost frame.

For example, consider the program

function inner() {
  var s = 0;
  for (var i = 0; i < 100000; i++) {
    s += i * i;
  }
  return s;
}

function trivial() {
  return inner();
}

for (var i = 0; i < 2000; i++) {
  trivial();
}

Before this change, d8 --prof --ignition --nocrankshaft and linux-tick-processor would produce:

  [JavaScript]:
   ticks  total  nonlib   name
   4885   83.4%   83.5%  Function: ~trivial a.js:15:17
    759   13.0%   13.0%  Function: ~inner a.js:7:15

After this change, we get

 [JavaScript]:
   ticks  total  nonlib   name
   5486   95.9%   96.2%  Function: ~inner a.js:7:15
      4    0.1%    0.1%  Function: ~trivial a.js:15:17

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

R=jgruber@chromium.org
BUG=v8:5530

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

R=mstarzinger@chromium.org

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

The operator in question does not call arbitrary JavaSciprt, nor throw,
nor trigger a lazy deoptimization. Nodes hence do not need a frame-state
representing the "after" state of the operation.

R=bmeurer@chromium.org

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

We don't need Code::CALL_IC for anything now that the CallICStub is
migrated and no longer hooks into the traditional IC system.

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

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

Port the Call feedback machinery from the interpreter to the CallICStub
as second step to unify the feedback collection. This removes a lot of
hand-written native code, and makes the runtime miss handler obsolete.
The next step will be to use the CallICStub from the interpreter as
well.

Drive-by-fix: Adjust CallIC/CallICTrampoline descriptors names.

R=mvstanton@chromium.org
BUG=v8:5049

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

R=machenbach@chromium.org
BUG=v8:5920
NOTRY=true

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

R=bmeurer@chromium.org

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

R=jgruber@chromium.org

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

This behavior was recently changed. Turns out that for some usage patterns
at least, populating the stub cache is significantly faster overall.

BUG=chromium:684428

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

This adds optional multi-architecture builds, allowing to compile
x86 and x64 in one build. The correctness fuzzer can be configured to
compare the two executables, e.g. to compare x86 to x64 run the
launcher with: --second-d8=clang_x86/d8 in an x64 build.

Configuring the executable's architecture is now simplified and
inferred from the gn build configuration.

Building for clusterfuzz has now a new canonical target that can be
used by the infrastructure (defaults to d8).

The clusterfuzz release builder is now defined to compile
multi-arch builds, which will have an effect as soon as the
infrastructure refers to the new clusterfuzz target.

BUG=chromium:673246
NOTRY=true
TBR=mstarzinger,jarin

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

BUG=

Review-Url: https://codereview.chromium.org/2663803002
Cr-Original-Commit-Position: refs/heads/master@{#42881}
Committed: https://chromium.googlesource.com/v8/v8/+/65ad1e35d9a97c1126a55cc9d3014598fd224259
Review-Url: https://codereview.chromium.org/2663803002
Cr-Commit-Position: refs/heads/master@{#42883}