BUG=chromium:651354

Change-Id: I15b2ee763882af369bf4b6274ce04e52dfb657e7
Reviewed-on: https://chromium-review.googlesource.com/457321
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43980}

This frees up the InterpreterAssembler for no longer being linked
into the main library.

BUG=v8:6055

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

BUG=v8:5977

Change-Id: Ic756fd44a945f98d51c0914dcc6c3b82111d170d
Reviewed-on: https://chromium-review.googlesource.com/456419Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43978}

For MIPS32, instructions ldc1 and sdc1 are moved into macro-assembler
and renamed as Ldc1 and Sdc1. The reason for placing them into
macro-assembler is that they emmit two or three instructions.

TEST=test/cctest/test-assembler-mips,
     test/cctest/test-code-stubs-mips,
     test/cctest/test-macro-assembler-mips
BUG=

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

This CL makes the interpreter reentrant by allowing different
activations to be live at the same time. The wasm interpreter keeps a
list of activations and stores the stack height at the start of each
activation. This information is used to unwind just one activation, or
show the right portion of the interpreter stack for each interpreter
entry frame.
The WasmDebugInfo object stores a mapping from frame pointer (of the
interpreter entry) to the activation id in order to identify the
activation based on the physical interpreter entry frame.

R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822

Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb
Reviewed-on: https://chromium-review.googlesource.com/453958
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43976}

BUG=v8:6055

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

This is in preparation of adding precise binary mode.

BUG=v8:5808

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

In the tick processor, in cases where there are a lot of ticks (e.g.
long running programs), JSON.stringify could throw a range exception
because the created string is too large.

Instead of creating the entire JSON string in memory, we now write the
top-level parts of the JSON manually, writing out the ticks individually
instead of all together.

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

The called runtime function never returns, thus we don't need to emit
return code afterwards.

R=ahaas@chromium.org

Change-Id: I4adb5492b1d5bcb8f644f9544137e07196ac61e4
Reviewed-on: https://chromium-review.googlesource.com/456507Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43972}

BUG=chromium:651354

Change-Id: Idcd7780f53ad07b3d782a66455f9c60addc2418d
Reviewed-on: https://chromium-review.googlesource.com/457317
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43971}

Original change's description:
> [wasm] Enable lazy compilation for asm-wasm pipeline
> 
> The validate-asm flag now implies lazy compilation.
> 
> R=​titzer@chromium.org, ahaas@chromium.org
> BUG=v8:5991
> 
> Change-Id: I00fb5ddbe13440941a3fafd9175cc9a5d182e15a
> Reviewed-on: https://chromium-review.googlesource.com/451318
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43952}

TBR=bradnelson@chromium.org,hablich@chromium.org,ahaas@chromium.org,clemensh@chromium.org,v8-reviews@googlegroups.com
NOTRY=true
BUG=v8:5991

Change-Id: Icc6ff9ebcd15fdd140d9fca2676ea2634783e6d5
Reviewed-on: https://chromium-review.googlesource.com/456508Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43970}

For CheckBounds(index,length) we know that the length must be in
Unsigned31 range. Thus there's no observable difference for index
values in the range [-2^31,-1] and the range [2^31,2^32-1], both
are considered out-of-bounds; also it's safe to truncate -0 to 0
wrt. CheckBounds. Thus we can safely pass Word32 truncation if the
index is in Integral32 \/ MinusZero. Usually this generates the same
code, but some index computations can benefit from the Word32 truncation
and avoid going to double because the result would be outside the valid
Signed32 or Unsigned32 ranges.

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

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

BUG=

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

When returning from the runtime function, move jssp back to csp. The
csp might have been changed by the runtime function, but jssp should
have been restored to its original value.

R=ahaas@chromium.org
BUG=v8:5822

Change-Id: I300263a586ca546a4d7f925730f1f38b680379ca
Reviewed-on: https://chromium-review.googlesource.com/457372Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43967}

R=jarin@chromium.org
BUG=

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

BUG=

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

We used to clear invocation counts when enabling precise coverage.
This is not necessary, and we could continue to use the existing
invocation counts on the heap. The old behavior can be achieved
by explicitly resetting the counts by polling coverage data.

R=jgruber@chromium.org,caseq@chromium.org
BUG=v8:5808

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

The flag is already on by default

R=clemensh@chromium.org

Change-Id: Ie4ede8191336a102cab9d7f972a3d10a15d1a54d
Reviewed-on: https://chromium-review.googlesource.com/456287Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43963}

Also move phi NodeVector in TryCloneBranch to temporary zone.

BUG=chromium:700364

Change-Id: Id19d51dae63ed5a6f5dccbba77a19b3663fd325e
Reviewed-on: https://chromium-review.googlesource.com/456285Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43962}

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

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4c534d4..9e7f0b1

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/2d86f95..d233eb2

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

Change-Id: I3270008c944240ae992a15463a09bef3887b0c92
Reviewed-on: https://chromium-review.googlesource.com/457083Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43960}

Improve visibility within the distributed wasm team.
Created wasm watchlist, and added wasm-team - the union of
MUC and MTV wasm teams.

BUG=

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

This used to be disabled implicitly and started to broke after some
refactoring in https://codereview.chromium.org/2758563002

BUG=chromium:703027

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

When we hit a call to String.prototype.concat builtin, where we can
infer that the receiver is a String and there's exactly one parameter,
which is of type PlainPrimitive, then we can reduce that to a call to
the StringAddStub instead, optionally converting the non-String - but
PlainPrimitive - parameter to a String.

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

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

Collect type information of return values.

Use *one* feedback slot per function for all its return
statements. For assignments, we currently use
several slots per function, because not all
assignments refer to the same variable.

Instead of the variable names, pass the
source location and print the function name.

Add an integration test for --type-profile that checks
for crashes.

Remove type feedback for assignments for now as it convolutes the output.

************ Function with 2 return statements ********
function testFunction(param, flag) {
  // We want to test 2 different return positions in one function.
  if (flag) {
    var first_var = param;
    return first_var;
  }
  var second_var = param;
  return second_var;
}

testFunction({});
testFunction(123, true);
testFunction('hello');
testFunction(undefined);
*******************************************************

************* Sample Output ***************************
Function: testFunction
424: Object
374: number
424: string
424: undefined
*******************************************************

Missing work:
* Handle fall-off returns
* Collect types for parameters
* Remove duplicates from the list of collected types and use a common base class.

BUG=v8:5935

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

We want to restrict structured cloning in Chrome to:
- postMessage senders and receivers that are co-located
in the same process
- indexedDB (just https).

For context, on the Chrome side, we will achieve the postMessage part
by using a mechanism similar to transferrables: the
SerializedScriptValue will have a list of wasm modules, separate from
the serialized data stream; and this list won't be copied cross
process boundaries. The IDB part is achieved by explicitly opting in
reading/writing to the serialization stream. To block attack vectors
in IPC cases, the default for deserialization will be to expect data
in the wasm transfers list.

This change is the V8 side necessary to enabling this design. We
introduce TransferrableModule, an opaque datatype exposed to the
embedder. Internally, TransferrableModules are just serialized data,
because we don't have a better mechanism, at the moment, for
de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
Context).

The chrome defaults will be implemented in the
serialization/deserialization delegates on that side. For the v8 side
of things, in the absence of a serialization delegate, the V8
serializer will write to serialization stream. In the absence of a
deserialization delegate, the deserializer won't work. This asymmetry
is intentional - it communicates to the embedder the need to make a
policy decision, otherwise wasm serialization/deserialization won't
work "out of the box".

BUG=v8:6079

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

Port 4f3e168c

Original Commit Message:

    This CL adds general lazy compilation support to WebAssembly, according
    to the design described in the design doc (see referenced bug).

    It's not used currently, but I tested locally that all tests succeed if
    I enable it by default.

    With a later CL, we will enable lazy compilation by default for
    validate-asm: https://chromium-review.googlesource.com/451318

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

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

This reverts commit 64a2287e.

Reason for revert: Breaks on arm64 msan, e.g. https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/13972/steps/Check%20-%20extra/logs/asm-wasm-f32. Will investigate tomorrow.

Original change's description:
> [wasm] Enable lazy compilation for asm-wasm pipeline
> 
> The validate-asm flag now implies lazy compilation.
> 
> R=​titzer@chromium.org, ahaas@chromium.org
> BUG=v8:5991
> 
> Change-Id: I00fb5ddbe13440941a3fafd9175cc9a5d182e15a
> Reviewed-on: https://chromium-review.googlesource.com/451318
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43952}

TBR=bradnelson@chromium.org,ahaas@chromium.org,clemensh@chromium.org,hablich@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5991

Change-Id: I8fe8d9268237c7397f6f22cd20ba6f23b9f5785a
Reviewed-on: https://chromium-review.googlesource.com/456506Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43953}

The validate-asm flag now implies lazy compilation.

R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5991

Change-Id: I00fb5ddbe13440941a3fafd9175cc9a5d182e15a
Reviewed-on: https://chromium-review.googlesource.com/451318
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43952}

This reverts commit ea4346be.

Reason for revert: This causes a crash in a Node.js test (parallel/test-repl-options). I can reproduce the crash locally. At a first glance, it doesn't look like we're doing anything terribly wrong in Node that explains the crash. I'll have a closer lock tomorrow. Feel free to reland if needed, we can always deactivate the test.  

Original change's description:
> [ic] Migrate StoreGlobal to data handler
> 
> BUG=v8:5561
> 
> Change-Id: If4c679c97af199ce1c90d055627186123bc88574
> Reviewed-on: https://chromium-review.googlesource.com/456698
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43944}

TBR=ishell@chromium.org,verwaest@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5561

Change-Id: I790ff9ab45016749fe2f3982045f497a995e282e
Reviewed-on: https://chromium-review.googlesource.com/456505Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43951}

Before:
Failure: expected <true> found <false>

After:
Failure: expected <0.4 +- 0.001> found <0.3>

R=ahaas@chromium.org

Change-Id: I304fd90112cb7131103863813e7b0920be2b5c04
Reviewed-on: https://chromium-review.googlesource.com/456284Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43950}

as InterpreterGenerator. This is in preparation for no longer including
the bytecode handler generation code in the main library.

BUG=v8:6055

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

When instantiating the wasm interpreter, pass the start address of the
global variables. This was nullptr before, leading to a crash if
debugging a program which accesses globals.
With test.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

Change-Id: I5f419790042ef9a00787df093a07e5e5835d55bd
Reviewed-on: https://chromium-review.googlesource.com/456219
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43948}

BUG=chromium:703028

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

Before, we were redirecting each function to the interpreter by iterating all
code and patching all call sites using this one function. The runtime was
hence quadratic if all functions were redirected to the interpreter as
done by the --wasm-interpret-all flag.
This CL fixes this to only iterate the code once and redirecting an
arbitrary number of function.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

Change-Id: Ia4f2e94a2468f9bef3035b599e1f8a18acf309da
Reviewed-on: https://chromium-review.googlesource.com/455785
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43946}

Defers a label in the LoadIC fast-path which was doing a call that was
forcing the entire LoadIC fast-path to have a frame. The label was
introduced in https://chromium-review.googlesource.com/c/455858/.

Change-Id: Icc8f7243c133cfa0ad60ede0d0f5651b639634e9
Reviewed-on: https://chromium-review.googlesource.com/456504Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43945}

BUG=v8:5561

Change-Id: If4c679c97af199ce1c90d055627186123bc88574
Reviewed-on: https://chromium-review.googlesource.com/456698Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43944}

BUG=chromium:694255

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

This fixes a bug where an exported function is being specialized, but
the callsite inside the JS_TO_WASM function was patched to call an
interpreter entry instead. We would not identify the call site as the
one to be patched during specialization, and would thus fail a DCHECK.

R=ahaas@chromium.org
BUG=v8:5822, chromium:702839

Change-Id: I148d98333051c399a4cb11bd9620b396f4eb261d
Reviewed-on: https://chromium-review.googlesource.com/456282
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43942}

Currently the incremental marking visitor treats elements of normalized
map caches weakly by coloring the caches grey without pusing to marking
deque.

The mark-compact prologue then clears all normalized map caches.

We can achieve similar effect by just clearing the caches in the marking
visitor.

BUG=chromium:694255

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