Until now keyed accesses to properties with string or symbol keys were
only optimized properly while the IC was monomorphic and would go
megamorphic as soon as there's another receiver map, even if the name
was still the same (i.e. the same symbol or internalized string). This
was a weird performance-cliff, that'll hurt modern code especially
because for symbols you can only access them via keyed loads and stores.

This CL fixes the state machine inside the ICs to properly transition to
POLYMORPHIC state (and stay there) as long as the new name matches the
previously recorded name. The FeedbackVector and TurboFan were already
able to deal with this and didn't need any updates.

On the micro-benchmark from the tracking bug we go from

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 431 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 5621 ms.

to

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 429 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 430 ms.

effectively eliminating the overhead for symbols completely, and
yielding a 13.5x performance boost.

This also seems to yield a 1% improvement on the ARES6 ML benchmark,
because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups.

Bug: v8:6367, v8:6278, v8:6344
Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897
Reviewed-on: https://chromium-review.googlesource.com/695108Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48261}

The context is the following proposal to make JSON a subset of
JavaScript: https://github.com/tc39/proposal-json-superset

There’s interest in performing a side investigation to answer the
question of what would happen if we stopped treating U+2028 and U+2029
as `LineTerminator`s *entirely*. (Note that this is separate from the
proposal, which just changes how these characters are handled in
ECMAScript strings.) This is technically a breaking change, and IMHO it
would be wonderful if we could get away with it, but no one really has
any data on whether or not we could. Adding this use counter lets us get
that data.

BUG=v8:6827

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa
Reviewed-on: https://chromium-review.googlesource.com/693155
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48260}

Bug: 
Change-Id: I2b1ae2f475e780606fa07db2cf861eb2537207d6
Reviewed-on: https://chromium-review.googlesource.com/695223Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48259}

Change-Id: I3b7e5f4fb9bc6cdad3582e19099fb97b2a0c7cb0
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/684185Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48258}

The KEYED_STORE_IC was never able to deal with stores to typed arrays
where the value being stored is not already a Number (i.e. either a Smi
or a HeapNumber). By extending it to also handle Oddballs (i.e. true,
false, undefined and null) and teaching TurboFan to also perform the
appropriate check plus the truncation to Number, we can easily support
this use case as well.

On the micro-benchmark in the bug report, we go from

  typedArrayStoreBool: 2975 ms.
  typedArrayStoreInt: 44 ms.

to

  typedArrayStoreBool: 43 ms.
  typedArrayStoreInt: 44 ms.

so that's roughly a 70x performance boost.

Bug: chromium:287773
Change-Id: I227419aeabc3f5b6793aa280a95448d03ac2f2dd
Reviewed-on: https://chromium-review.googlesource.com/691731
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48257}

R=gdeepti@chromium.org

Bug: 
Change-Id: Ic2e519d24354b3327a92daa0d4d6e06c9ca4605e
Reviewed-on: https://chromium-review.googlesource.com/687056
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48256}

With --wasm-trace-memory, both compiled code and the interpreter will
output each memory load or store. This helps to debug miscompilations in
emscripten or in V8, like the referenced bug.

R=titzer@chromium.org

Bug: chromium:718858
Change-Id: I90704d164975b11c65677f86947ab102242d5153
Reviewed-on: https://chromium-review.googlesource.com/684316Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48255}

The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
as far as I can tell only definitely side-effect free) way to check whether an
arbitrary object is a TypedArray - either generally TypedArray or a specific
one like Uint8Array. Using the getter is thus emerging as the general pattern
to detect TypedArrays, even Node.js now adapted it starting with

  https://github.com/nodejs/node/pull/15663

for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
now.

The getter returns either the string with the TypedArray subclass name
(i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
This can be implemented with a simple elements kind dispatch, instead of
checking the instance type and then loading the class name from the
constructor, which requires a loop walking up the transition tree. This
CL ports the builtin to CSA and TurboFan, and changes the logic to a
simple elements kind check. On the micro-benchmark mentioned in the
referenced bug, the time goes from

  testIsArrayBufferView: 565 ms.
  testIsTypedArray: 2403 ms.
  testIsUint8Array: 3847 ms.

to

  testIsArrayBufferView: 566 ms.
  testIsTypedArray: 965 ms.
  testIsUint8Array: 965 ms.

which presents an up to 4x improvement.

Bug: v8:6874
Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48254}

Change-Id: Iac4a95a0c094472d887d89bbf5d6189988c56f7c
Reviewed-on: https://chromium-review.googlesource.com/692016
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48253}

Bug: V8:6532
Change-Id: I6713e1c01ec669b7fa9a09bb75fbecff12f6cc22
Reviewed-on: https://chromium-review.googlesource.com/685949
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48252}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b376554..ce6d3d8

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

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

- Moves leak sanitizer code to callers of OS:: Memory functions.
- Changes signature of OS::ReleasePartialRegion to be more generic,
  removing the parameters that only make sense as part of VirtualMemory.

Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2f1401c9b0856b2eaf36b80b5f141e935ef63e1c
Reviewed-on: https://chromium-review.googlesource.com/685741Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48250}

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b6bab93..8ec7b14

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

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

Remove more "using" statements.

Bug: chromium:746958
Change-Id: I2f9c45b1ff1d51fc58b7a702fee046ba3c6a7c17
Reviewed-on: https://chromium-review.googlesource.com/693862Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#48248}

This improves performance of ArrayBuffer.isView by roughly 2.5x itself,
and enables optimizations across ArrayBuffer.isView calls, i.e. map
checks can be eliminated across. This was discovered in a related Node
pull request (https://github.com/nodejs/node/pull/15663).

Bug: v8:6868
Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522
Reviewed-on: https://chromium-review.googlesource.com/691660Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48247}

This reverts commit 3c4bc27f.

Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=770257

Original change's description:
> Reland "[turbofan] eagerly prune None types and deadness from the graph"
> 
> This is a reland of e1cdda25
> Original change's description:
> > [turbofan] eagerly prune None types and deadness from the graph
> > 
> > In addition to using the {Dead} node to prune dead control nodes and nodes that 
> > depend on them, we introduce a {DeadValue} node representing an impossible value 
> > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > of a node with type {None} as dead.
> > 
> > Bug: chromium:741225
> > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > Reviewed-on: https://chromium-review.googlesource.com/641250
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48208}
> 
> Bug: chromium:741225
> Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> Reviewed-on: https://chromium-review.googlesource.com/692034
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48232}

TBR=jarin@chromium.org,tebbi@chromium.org

Change-Id: Ied8da411a9c8cbe4ed2e1d3e98a76162c2834c97
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:741225 chromium:770257
Reviewed-on: https://chromium-review.googlesource.com/693235Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48246}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/57716b3..b376554

Rolling v8/third_party/android_tools: https://chromium.googlesource.com/android_tools/+log/aadb2fe..ca9dc72

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/9a255f5..b6bab93

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

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

In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.

With this change, we wait until after all argument conversions are done to set
the flag.

Bug: chromium:769846

R=bradnelson@chromium.org

Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}

Changing "DoubleDigitGreaterThan", which was consuming the result of a
multiplication, to "ProductGreaterThan", which performs both steps.

Bug: v8:6791
Change-Id: I7dbad350ff9b8228e11682d9691a1574ea5b0b58
Reviewed-on: https://chromium-review.googlesource.com/683614Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48243}

This reverts commit 1f99c66b.

Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226

Original change's description:
> [wasm] always allocate memory when guard regions are needed
> 
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
> 
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
> 
> Bug: chromium:769637
> Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
> Reviewed-on: https://chromium-review.googlesource.com/693137
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48240}

TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:769637
Reviewed-on: https://chromium-review.googlesource.com/692918Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48242}

based on the existing Number.parseInt.

Bug: v8:6791
Change-Id: I9169a4695807a3e435e343d239431ae7f6ccf2a1
Reviewed-on: https://chromium-review.googlesource.com/685990Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48241}

When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.

The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.

Bug: chromium:769637
Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
Reviewed-on: https://chromium-review.googlesource.com/693137Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48240}

It was working fine for bases 2, 4, and 16; but not for 8 and 32.
We have to take carryover from one digit to the next into account
when bits_per_character is not a divisor of kDigitBits.

Bug: v8:6791
Change-Id: Ia2cd13bdddb04b8abf1e4381e66ba4c88826fbf9
Reviewed-on: https://chromium-review.googlesource.com/685813Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48239}

Bug: chromium:738865
Change-Id: I070982d8a4fe2595673ca727973ad8b723050c2f
Reviewed-on: https://chromium-review.googlesource.com/692255Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48238}

TBR: ofrobots@google.com, yangguo@chromium.org
Bug: 
Change-Id: I6cb0704acabf9a7f2334de539a6600db8607baef
Reviewed-on: https://chromium-review.googlesource.com/691720
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48237}

This ports:
https://chromium-review.googlesource.com/c/chromium/src/+/688742

TBR=agable@chromium.org

Bug: chromium:731091
Change-Id: I99b6bfcc769a5f3c429668c2d36518bcac80f3cf
Reviewed-on: https://chromium-review.googlesource.com/692634Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48236}

Change the default to false. Block coverage will need to be
enabled explicitly via inspector protocol, which is already
being done.

R=franzih@chromium.org

Bug: v8:6738
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I08684ce7b501981bc376a6bc6181fabac9628a63
Reviewed-on: https://chromium-review.googlesource.com/689234Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48235}

This reverts commit 1cc93be0.

Reason for revert: http://crbug.com/769976

Original change's description:
> [arm64] Add slot copier to masm and use in builtins
> 
> Abstract some stack slot copies through a macro assembler function. This
> eliminates some non-paired stack operations.
> 
> Bug: v8:6644
> Change-Id: Icaa3ebb1bec42587ad461bd548a4225c7b4e5d15
> Reviewed-on: https://chromium-review.googlesource.com/685238
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/master@{#48177}

TBR=rmcilroy@chromium.org,martyn.capewell@arm.com,bmeurer@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:6644
Change-Id: I9044df7c2be028748d85b7007008331a2aa8173f
Reviewed-on: https://chromium-review.googlesource.com/691874
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48234}

And some refactoring to the existing code for LiveEdit.

R=jarin@chromium.org

Change-Id: Ic1d626db9722b39cbcd83bf6878fc24d6094e612
Reviewed-on: https://chromium-review.googlesource.com/687014
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48233}

This is a reland of e1cdda25
Original change's description:
> [turbofan] eagerly prune None types and deadness from the graph
> 
> In addition to using the {Dead} node to prune dead control nodes and nodes that 
> depend on them, we introduce a {DeadValue} node representing an impossible value 
> that can occur at any position in the graph. The extended {DeadCodeElimination}
> prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> the effect chain when possible. The remaining uses of {DeadValue} are handled
> in {EffectControlLinearizer}, where we always have access to the effect chain.
> In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> of a node with type {None} as dead.
> 
> Bug: chromium:741225
> Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> Reviewed-on: https://chromium-review.googlesource.com/641250
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48208}

Bug: chromium:741225
Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
Reviewed-on: https://chromium-review.googlesource.com/692034Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48232}

We were unnecessarily storing everything as uint32_t, even though many items in
the preparsed scope data can be stored as uint8_t. This CL also adds an
(internal) API which abstracts away the actual data storing, so the backing
store can be made even more efficient (e.g., use only 1-3 bytes for some
uint32_t values, if they fit) without affecting other parts of the code.

BUG=v8:5516,chromium:762492

Change-Id: I7cd4d91dc11f87f8aec9c7584044a6f2a59b73ba
Reviewed-on: https://chromium-review.googlesource.com/684182
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48231}

Change-Id: Id2eef89f0eba3c59bcdb490e7d986b4b3af0ff9b
Reviewed-on: https://chromium-review.googlesource.com/657677Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48230}

Verify that both UTF-8 decoders (incremental and non-incremental one) match the
expectations.

Also cleanup / harden the UTF-8 handling code, as suggested in
https://chromium-review.googlesource.com/c/v8/v8/+/671020/ .


BUG=chromium:765608

Change-Id: I6344d62ca15b75ac8e333421c94c4aa35ab8190d
Reviewed-on: https://chromium-review.googlesource.com/681217
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48229}

Port for: https://chromium-review.googlesource.com/c/v8/v8/+/684017

TEST=cctest/test-run-wasm-64/RunWasmCompiled_Regression_6858
BUG=

Change-Id: Ib9640853ea15d73967683c1315e6b54b5b6cc3be
Reviewed-on: https://chromium-review.googlesource.com/689794
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48228}

Bug: chromium:694255
Change-Id: Ie596e02207f13762dbfa77e4fe65950913302b47
Reviewed-on: https://chromium-review.googlesource.com/690075Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48227}

Bug: chromium:645094
Change-Id: I04a7f6a4073a6a5c81546863d6f1f371fc74e65d
Reviewed-on: https://chromium-review.googlesource.com/691836
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48226}

Change-Id: I9eec3c31cdf1441d3187e5d882ca4b88e7b698e7
Reviewed-on: https://chromium-review.googlesource.com/691726Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48225}

in marking worklist.

Bug: chromium:769173
Change-Id: I4b3ce27d37bec19ec5cc342b4d26a2a45af34b5f
Reviewed-on: https://chromium-review.googlesource.com/691728Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48224}

We had dangling pointers by storing a raw pointer and then discarding
the unique_ptr holding it alive, and we had lots of redundant
information there.
This CL refactors the interface to take a format string and a variable
number of argument.

R=titzer@chromium.org

Change-Id: I8eb6ccd19d307e2477c97a3e5e7f537b5671a891
Reviewed-on: https://chromium-review.googlesource.com/690196
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48223}

Bug: 
Change-Id: I58ce9a0f42dfa81c8e8affa2377c5cc0d08a35e2
Reviewed-on: https://chromium-review.googlesource.com/691714
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48222}