This switches all deoptimization events to go through use one single
continuation builtin (i.e. {Builtins::kNotifyDeoptimized}) instead of
handling builtin continuation specially. Fewer moving pieces.

R=jarin@chromium.org

Change-Id: Ic8a2316fa2f5c8717b4d50d1a619b87a38011564
Reviewed-on: https://chromium-review.googlesource.com/712156
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48496}

Bug: v8:6557
Change-Id: I01f065b74e3c568e577a3ee2caca68f24293c1cb
Reviewed-on: https://chromium-review.googlesource.com/686763Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48495}

The degenerate br_table case should be handled specially only in the
graph building consumer. There it is necessary for avoiding the
construction of a degenerate Switch node, which would cause a DCHECK
error in instruction selection.
For other backends, like the baseline compiler, we should handle it as
a br_table, because the signature is different to a br.

Drive-by: Fix redundant validation.

R=titzer@chromium.org

Bug: v8:6600
Change-Id: Ia430b6d251eb1323848977388ed95a112f8c76f7
Reviewed-on: https://chromium-review.googlesource.com/715616Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48494}

This propagates the existing type of a {JSAdd} node back to the newly
created {Allocate} node. There are cases where said type is {None}.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-772720
BUG=chromium:772720

Change-Id: Iab18d2108a789b51db4e405f7f335c5c0ca6f686
Reviewed-on: https://chromium-review.googlesource.com/708796Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48493}

Bug: chromium:764219
Change-Id: I99d1192c5c0f2b8bf47e0f193a0c4d9c00477466
Reviewed-on: https://chromium-review.googlesource.com/712454
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48492}

When an immediate does not fit an add instruction we use a temporary register to
hold the value, using movw/movt to encode it. However, in order to remove a use
of r9 in TurboFan's code generator, we need to cope with no scratch registers
being available. That is to say that the destination and source registers are
the same, and `ip` is not available to use.

In this case, we can split an add instruction into a sequence of additions:
```
UseScratchRegisterScope temps(...);
Register my_scratch = temps.Acquire();
__ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd
                                // add r0, r0, #0xab00
```

As a drive-by fix, make the disassembler test fail if we expected a different
number of instructions generated.

Bug: v8:6553
Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf
Reviewed-on: https://chromium-review.googlesource.com/685014Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48491}

The VALIDATE macro should only be used for tests that do not have any
side effect, because the side effect will only be executed if
validation is active or in debug builds (because the condition is
DCHECKed there).
The TypeCheckBreak method has side effects since a while, since it
inserts unreachable values on the stack.
This did not lead to failures so far, since we only have validating
users of the WasmFullDecoder. This will change once we have general
lazy compilation of wasm modules, e.g. for tier-up.

R=titzer@chromium.org

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

R=titzer@chromium.org

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

R=jkummerow@chromium.org

Bug: v8:6791
Change-Id: Id050eb583af2977e27a91f6ff9ab82c72df0ca2e
Reviewed-on: https://chromium-review.googlesource.com/711849Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48488}

R=jkummerow@chromium.org

Bug: v8:6791
Change-Id: Id499a47cbb545c7ba4bffd1c1935846be6025b5e
Reviewed-on: https://chromium-review.googlesource.com/712255
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48487}

Also add tests for Object::SameValue.

R=jkummerow@chromium.org

Bug: v8:6791
Change-Id: I0611044dcfee4c6ba836629cf82d1589135e4ab0
Reviewed-on: https://chromium-review.googlesource.com/712034Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48486}

R=jkummerow@chromium.org

Bug: v8:6791
Change-Id: I7e99a8aa2aa65e78a8d4288f496d496600063bfe
Reviewed-on: https://chromium-review.googlesource.com/712534
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48485}

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

- remove unused Runtime_GetLanguageTagVariants
- add test for another related bug (chromium:770452) as well as for 
chromium:770450 . 

Bug: chromium:770450, chromium:770452
Test: intl/general/invalid-locale.js
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4496a4a5421000faa0e37aed85fea21ceb487998
Reviewed-on: https://chromium-review.googlesource.com/710816Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48483}

This reverts commit 4cf47645.

Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch.

Original change's description:
> Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"
> 
> This fixes the issues 
> https://bugs.chromium.org/p/chromium/issues/detail?id=772873 
> and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.
> 
> One problem was that mutating an effect node into Unreachable confused 
> the LoadElimination sidetables, so I just always create a new node now.
> 
> The other problem was that UpdateBlockControl() was executed after 
> UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
> So now I make sure that UpdateEffectPhi() is always executed last.
> 
> This is a reland of 6ddb5e7d
> Original change's description:
> > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
> > 
> > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the 
> > graph end. This fixes issues with later phases running DeadCodeElimination and
> > introducing new DeadValue nodes when processing uses of Unreachable.
> > 
> > This is a reland of 3c4bc27f
> > 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}
> > 
> > Bug: chromium:741225
> > Change-Id: I5702ec34856c075717162153adc765774453c45f
> > Reviewed-on: https://chromium-review.googlesource.com/702264
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48366}
> 
> Bug: chromium:741225
> Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f
> Reviewed-on: https://chromium-review.googlesource.com/709214
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48469}

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

Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:741225
Reviewed-on: https://chromium-review.googlesource.com/715096Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48482}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/adaf9e5..ddb142b

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a48a6af..072921b

Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/08cb956..21d33b1

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b3169f9..0c09c7a

Rolling v8/tools/luci-go: https://chromium.googlesource.com/chromium/src/tools/luci-go/+log/9f54aa9..45a8a51

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

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

In the current implementation of hash code for objects (identity hash),
we do not bother to shift the hash when we retrieve it from the 
hash-length bitfield in a property array. (Even worse, we store shifted
value even if we do not have property array or inside dictionaries.)
That means that the hash-code for objects is always divisible by 1024.
Since our hash table uses a simple masking with (2^logsize - 1) to 
obtain the bucket, we get terrible hash collisions - essentially, our
hash table degenerates to a linked list for fewer than 1024 elements.

This CL always shifts the hash code so that the value in the lowest 
21 bits is uniformly distributed.

This results in big improvements on medium to large hash tables.
A program storing 1M elements into a WeakMap gets roughly
17x faster.  A program retrieving 1M elements from a Map 
improves even more dramatically (>100x).

const a = [];
for (let i = 0; i < 1e6; i++) a[i] = {};

const m = new Map();
console.time("Map.set");
for (let i = 0; i < 1e6; i++) {
  m.set(a[i], i);
}
console.timeEnd("Map.set");

console.time("Map.get");
let s = 0;
for (let i = 0; i < 1e6; i++) {
  s += m.get(a[i]);
}
console.timeEnd("Map.get");

const w = new WeakMap();
console.time("WeakMap.set");
for (let i = 0; i < 1e6; i++) {
  w.set(a[i], i);
}
console.timeEnd("WeakMap.set");

Before the fix:

Map.set: 157.575000
Map.get: 28333.182000
WeakMap.set: 6923.826000

After the fix:

Map.set: 178.382000
Map.get: 185.930000
WeakMap.set: 409.529000

Note that Map does not suffer from the hash collision on insertion because
it uses chaining (insertion into linked list is fast regardless of size!), and
we cleverly avoid lookup in the hash table on update if the key does not have 
identity hash yet. This is in contrast to the WeakMap, which uses 
open-addressing, and deals with collisions on insertion.

Bug: v8:6916
Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4
Reviewed-on: https://chromium-review.googlesource.com/713616Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48480}

and add the implementations for BitwiseNot, Increment, Decrement.
This CL teaches the respective bytecode handlers about BigInts,
and collects kBigInt type feedback for them (which TF discards
for now, substituting "any").

Bug: v8:6791
Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9
Reviewed-on: https://chromium-review.googlesource.com/706101
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48479}

This reverts commit d9a25842.

Reason for revert: 

I'm reverting this CL for a few reasons. #2 is the most significant and I should have thought of that before making a switch. Sorry for that.   

1) perf-regression: http://crbug.com/769706
2) http://crbug.com/612010 : ICU timezone update is not propagated to zygote process so that new tabs will hold on to an old timezone even after a timezone change on Linux and Chrome OS. 
3) http://crbug.com/754053 : OS timezone detection issues on macOS 10.13, Ubutu 16, RHEL 7, SuSe Linux 12 or newer. ; it's being fixed. So, it actually ok.  
4) http://crbug.com/771868 : timezone wrong in gmail: If it's due to #3, we're fine because it's fixed. If not, we need to look more.

Original change's description:
> Enable icu-timezone-data by default
> 
> This will introduce a new behavior on POSIX(-like) platforms. Timezone
> names inside parentheses after GMT offset will not be 3-4 letter
> abbreviation any longer. They'll be human-readable names in the current
> default locale. This matches the current Windows behavior.
> 
> new Date(2017, 5, 22).toString()
> new Date(2017, 11, 22).toString()
> 
> Current:
> 
> Thu Jun 22 2017 00:00:00 GMT-0700 (PDT)
> Fri Dec 22 2017 00:00:00 GMT-0800 (PST)
> 
> New in en-US locale:
> 
> Thu Jun 22 2017 00:00:00 GMT-0700 (Pacific Daylight Time)
> Fri Dec 22 2017 00:00:00 GMT-0800 (Pacific Standard Time)
> 
> New in German locale:
> 
> Thu Jun 22 2017 00:00:00 GMT-0700 (Nordamerikanische Westküsten-Sommerzeit)
> Fri Dec 22 2017 00:00:00 GMT-0800 (Nordamerikanische Westküsten-Normalzeit)
> 
> BUG=v8:6031, v8:2137, v8:6076
> TEST=mjsunit/icu-date-lord-howe.js, mjsunit/icu-date-to-string.js
> 
> Change-Id: I4e7fd8b3ddae5c7779e220c4c101e45904fcdc01
> Reviewed-on: https://chromium-review.googlesource.com/625164
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47953}

TBR=adamk@chromium.org,littledan@chromium.org,jshin@chromium.org

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

Bug: v8:6031, v8:2137, v8:6076, chromium:769706, chromium:612010, chromium:771868
Change-Id: I60d75467ee21975d3a235344b01c0d2d44a7da96
Reviewed-on: https://chromium-review.googlesource.com/713404Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48478}

This roll includes:
- [inspector_protocol] fixed compatibility with latest jinja 2.9.6
- [inspector_protocol] removed unused variable
- Follow up on alph's review comments.
- Provide default escape implementation for latin and wide strings.
- Allow escaping utf8 strings in embedders that operate std::string.
- Upload inspector_protocol changes to Gerrit by default
- [inspector_protocol] Fix building with non-ASCII paths
- [inspector_protocol] added StringUtil::toDouble method as requirement
- Add const char* overloads to ErrorSupport

BUG=chromium:743313
R=dgozman@chromium.org

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic81a62c638bf592ae65c84055d53d926e50715ac
Reviewed-on: https://chromium-review.googlesource.com/713538Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48477}

Port fc413158

Original Commit Message:

    ObjectTriple isn't used since f1ec44e2. Delete
    it, and simplify CEntryStub on all backends.

R=martyn.capewell@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I4897783bb848e016d93731585e6891033fa4d4cf
Reviewed-on: https://chromium-review.googlesource.com/714022Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#48476}

This CL adds an uma stat to track the throughput
of lazy compilation for wasm functions in KB/s.

BUG=chromium:770618
R=kschimpf@chromium.org,bradnelson@chromium.org,isherman@chromium.org

Change-Id: Iad06cfb1f185f7e2ab6b0198282c03c3d8f29e2e
Reviewed-on: https://chromium-review.googlesource.com/706276
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48475}

This is a reland of cc237d87
Original change's description:
> Reland "[wasm] trap handlers: fall back on old signal handler"
> 
> This is a reland of ee4fe896
> Original change's description:
> > [wasm] trap handlers: fall back on old signal handler
> > 
> > This is primarily needed to test D8 under ASan. ASan installs a signal handler
> > early in the process startup to show stack traces from crashes. We need to make
> > sure that if V8 does not handle a signal then the existing handler gets a
> > chance.
> > 
> > This change only applies when using V8's default signal handler. When
> > integrating with the embedder's signal handler the behavior is unchanged.
> > 
> > Bug: chromium:771948
> > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> > Reviewed-on: https://chromium-review.googlesource.com/705823
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Commit-Queue: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48429}
> 
> Bug: chromium:771948
> Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
> Reviewed-on: https://chromium-review.googlesource.com/710114
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48435}

Bug: chromium:771948
Change-Id: I781dfe356a728760090b6ccfa58212096e8f20c8
Reviewed-on: https://chromium-review.googlesource.com/713956Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48474}

Port 193dcf76

Original Commit Message:

    Pair some stack ops so that they deal with an even numbers of registers, add
    padding around profile entry calls, and delete some unused macro assembler code.

R=martyn.capewell@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I017ccc699839b04bc7295d00c45e315f7cf074c1
Reviewed-on: https://chromium-review.googlesource.com/713996Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#48473}

There are currently no decisions based on the CPU implementor, variant
or part values for ARM64, and the code to fetch those values was not
compatible with Fuchsia/ARM64.

Bug: chromium:772031
Change-Id: I2305fc7a97d8c0a24bb0ad115447665976e5814a
Reviewed-on: https://chromium-review.googlesource.com/706642Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Rodolph Perfetta <rodolph.perfetta@arm.com>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48472}

This CL teaches the respective bytecode handlers and standalone
stubs about BigInts, and collects "kBigInt" type feedback for them.
Just like for other binary ops, that feedback is converted to "any"
for TurboFan for now.

Bug: v8:6791
Change-Id: I0709cc77dc248dad506207c7b35b63c80b1ef96a
Reviewed-on: https://chromium-review.googlesource.com/699424Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48471}

AST printing was printing the literal of the ParseInfo, which is the
current function being parsed. However, for eager compilation of inner
literals, this may not be the function being compiled, which is in the
CompilationInfo.

So, for --print-ast, we have to get the FunctionLiteral from
CompilationInfo.

Bug: chromium:771653
Change-Id: I2088e1f1f7b8a3d664aae65cab699a641e5fd302
Reviewed-on: https://chromium-review.googlesource.com/712354Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48470}

This fixes the issues 
https://bugs.chromium.org/p/chromium/issues/detail?id=772873 
and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.

One problem was that mutating an effect node into Unreachable confused 
the LoadElimination sidetables, so I just always create a new node now.

The other problem was that UpdateBlockControl() was executed after 
UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
So now I make sure that UpdateEffectPhi() is always executed last.

This is a reland of 6ddb5e7d
Original change's description:
> Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
> 
> Now, the EffectControlLinearizer connects all occurrences of Unreachable to the 
> graph end. This fixes issues with later phases running DeadCodeElimination and
> introducing new DeadValue nodes when processing uses of Unreachable.
> 
> This is a reland of 3c4bc27f
> 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}
> 
> Bug: chromium:741225
> Change-Id: I5702ec34856c075717162153adc765774453c45f
> Reviewed-on: https://chromium-review.googlesource.com/702264
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48366}

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

This is a reland of ed6f00fb
Original change's description:
> [modules] Implement import.meta proposal
> 
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
> 
> This adds an example implementation to d8 that sets meta.url.
> 
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}

TBR=adamk@chromium.org

Bug: v8:6693
Change-Id: Ie2d746ad996a56ed6ff50b832f320fe44e02f231
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/712834Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48468}

Bug: v8:6917
Change-Id: I3889cd0d059c3473a7b83eb298734a7a6a8a1de5
Reviewed-on: https://chromium-review.googlesource.com/712175Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48467}

This reverts commit b0ced926.

Reason for revert: Build breakage - https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/20832

Original change's description:
> Track committed array buffer size rather than allocation length
> 
> WebAssembly creates ArrayBuffers with large allocations where only a small
> amount is committed. The uncommitted address space should not be counted as used
> memory. Doing so can lead to the GC spending unnecessary time collecting memory
> when there is not really pressure.
> 
> Bug: 
> Change-Id: Ife7b84e9858e87faabc360a61f887b2fda6d99db
> Reviewed-on: https://chromium-review.googlesource.com/710227
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48462}

TBR=mlippautz@chromium.org,eholk@chromium.org

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

Adds some necessary padding to ensure the frame is 16-byte aligned.
We don't yet consider the bailout state, which will be handled separately.

This patch also improves the code generated for ContinueTo*Builtin* stubs.

Finally, it adds a test that checks the return value for Array.map in
the case where a LAZY deopt results in a topmost builtin continuation
frame - this is easy to break if the padding for the result is done
incorrectly in NotifyBuiltinContinuation, but was not detected by existing
tests.

Bug: v8:6644
Change-Id: Id1a294950cdf535e2bfdb0ed27c67f077ec34f8a
Reviewed-on: https://chromium-review.googlesource.com/704835
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48465}

Instead of using the size of the whole code object, just use the size
of the instructions, because only there faults can happen.

R=eholk@chromium.org

Bug: v8:5277
Change-Id: Ia5768891ec3c1ee5ad8affc9486e044d79e23146
Reviewed-on: https://chromium-review.googlesource.com/712536Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48464}

Only change over original: Init sig_index to 0 at
function-body-decoder-impl.h:168, to make MSAN happy on error path.

R=titzer@chromium.org

Change-Id: I9ac17215360523b656b10d2466201001b65992c0
Reviewed-on: https://chromium-review.googlesource.com/712655Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48463}

WebAssembly creates ArrayBuffers with large allocations where only a small
amount is committed. The uncommitted address space should not be counted as used
memory. Doing so can lead to the GC spending unnecessary time collecting memory
when there is not really pressure.

Bug: 
Change-Id: Ife7b84e9858e87faabc360a61f887b2fda6d99db
Reviewed-on: https://chromium-review.googlesource.com/710227Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48462}

Prepared by:
https://chromium-review.googlesource.com/c/chromium/tools/build/+/712036

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

Currently it's hard to reason about the hung tests on worker processes.
This adds simple output when we're trying to kill a hung process.

Change-Id: Iae5e14dac70a8149c074043dd00cbf10e4d5f3de
Reviewed-on: https://chromium-review.googlesource.com/712455Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48460}

This patch is a first step towards target independent tests for the
CodeGenerator's AssembleMove and AssembleSwap methods.

The tests on top of which this builds would only make sure that no assertions
were triggered while generating moves, and that the hardware is happy executing
them. We want to do more and check that the generated code performs correctly.

In a nutshell, this introduces a facility that can do the following:

  - Setup an environment with registers and stack slots initialised with random
    values.
  - Perform a list of randomly generated moves and/or swaps on those.
  - Return the resulting environment.

This is a first step and therefore is lacking a few things which will be
implemented as follow-ups:

  - Support for kSimd128 moves and swaps.
  - Support large offsets for stack moves, as well as positive and negative.
  - Compare the resulting environment against the result of a reference
    simulation.

For more background information, see this design document:
https://docs.google.com/document/d/1KpioxCmtiB_9RaPaRidZPVtKlZ2BaNKGPYUjKFihhK0

Bug: v8:6848
Change-Id: Ie7dc837f4444df010ab58c64b722d40ee5d2af72
Reviewed-on: https://chromium-review.googlesource.com/677398Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48459}

The optimization keeps dying maps alive for several GCs to mitigate
code deoptimization with weak maps.

This patch disables the optimization to see if it still needed.

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

R=clemensh@chromium.org

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