BUG=

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

[turbofan] Treat the INT32 state of a truncating binary op IC as number or oddball on 32-bit machines.

This was causing a few unexpected deopt loops.

BUG=v8:5320

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

Original issue's description:
> Release streamed script resources after it was compiled
>
> Otherwise, we'd hold on to the resources until the embedder frees them
> which might take a long time
>
> R=marja@chromium.org,verwaest@chromium.org
> BUG=
>
> Committed: https://crrev.com/877dac34465c018bb534b7781fbe242ae4e33c32
> Cr-Commit-Position: refs/heads/master@{#38999}

TBR=marja@chromium.org,verwaest@chromium.org
BUG=chromium:642347

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

BUG=chromium:148757

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

Now incremental marking tracing outputs isolate and timestamp:

[41894:0x21efec0]    17253 ms: [IncrementalMarking] Start (old space step)

This patch also adds walltime duration of incremental marking to GC trace output.

BUG=

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

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=

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

With this CL we use isolate->native_context() to provide a context for
the CEntryStub of the runtime call. The native_context() is sufficient
here because Runtime::kWasmThrowTypeError does not use the context.

R=titzer@chromium.org
TEST=mjsunit/wasm/ffi-error.js
BUG=chromium:639492

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

R=ulan@chromium.org
BUG=

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

Revert of Release streamed script resources after it was compiled (patchset #1 id:1 of https://codereview.chromium.org/2297523002/ )

Reason for revert:
Seems to break webkit unit tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9360
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/5503

Original issue's description:
> Release streamed script resources after it was compiled
>
> Otherwise, we'd hold on to the resources until the embedder frees them
> which might take a long time
>
> R=marja@chromium.org,verwaest@chromium.org
> BUG=
>
> Committed: https://crrev.com/877dac34465c018bb534b7781fbe242ae4e33c32
> Cr-Commit-Position: refs/heads/master@{#38999}

TBR=marja@chromium.org,verwaest@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

R=machenbach@chromium.org
BUG=

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

Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f

Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5

Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3

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

Committed: https://crrev.com/3b8a2e5129fec64674bb0191cba5aa4592d08d5f
Review-Url: https://codereview.chromium.org/2289063002
Cr-Original-Commit-Position: refs/heads/master@{#38995}
Cr-Commit-Position: refs/heads/master@{#39010}

Port https://codereview.chromium.org/2267753002/

BUG=474921
TBR=jochen@chromium.org, kjellander@chromium.org, vogelheim@chromium.org

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

R=marja@chromium.org,verwaest@chromium.org
BUG=

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

For arch variants loongson and r1 neg instruction does not change the
sign for NaN-like operands, the same as r2 neg. This fix adjusts macro
assembler Neg_s and Neg_d arch variant logic so the correct code would
be generated for loongson and r1.

BUG=

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

BUG=v8:5273

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

Put the types for the Date builtins into the TypeCache, and add
support for Date.prototype.getDay and Date.prototype.getMinutes.

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

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

This replaces the target-selection options (such as "--enable-vfp3")
with a simpler, absolute "--arm-arch" option. This eliminates inferences
and avoids surprising behaviour in impossible situations (such as
"--enable-vfp3 --no-enable-armv7").

The available options are:
    --arm-arch=armv6          ARMv6 + VFPv2
    --arm-arch=armv7          ARMv7 + VFPv3-D32 + NEON
    --arm-arch=armv7+sudiv    ARMv7 + VFPv4-D32 + NEON + SUDIV
    --arm-arch=armv8          ARMv8 (+ all of the above)

For now, the default setting is "armv8", which results in behaviour very
similar to the existing defaults.

BUG=v8:5077

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

Instead of creating them on demand all over the place.

I plan to link ScopeInfos together, and having one place where all
ScopeInfos are created will make this easier.

R=verwaest@chromium.org,adamk@chromium.org
TBR=mstarzinger@chromium.org
BUG=v8:5215

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

The comment for the Proxy::New functions seems inaccurate and is
currently identical to Map::New:

3090   /**
3091    * Creates a new empty Map.
3092    */
3093   static Local<Map> New(Isolate* isolate);

This commit updates the comment to describe that it creates a Proxy and
not a Map.

BUG=

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

This CL is a prequisite for the stack machine changes, which will need
to use temporaries in various places due to the stack height requirements
on blocks.

R=ahaas@chromium.org,bradnelson@chromium.org
BUG=

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

It emits spurious -Wmaybe-uninitialized warnings. Initializing these variables
shouldn't do any harm (with an optimizing compiler), so this seems the quickest
way to mollify gcc.

BUG=chromium:148757

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

Otherwise, we'd hold on to the resources until the embedder frees them
which might take a long time

R=marja@chromium.org,verwaest@chromium.org
BUG=

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

Reason for revert:
Breaks tsan build generation:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11441

Original issue's description:
> Update V8 DEPS.
>
> Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8
>
> Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f
>
> Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5
>
> Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3
>
> TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
>
> Committed: https://crrev.com/3b8a2e5129fec64674bb0191cba5aa4592d08d5f
> Cr-Commit-Position: refs/heads/master@{#38995}

TBR=hablich@chromium.org,vogelheim@chromium.org,v8-autoroll@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/2290163002
Cr-Commit-Position: refs/heads/master@{#38998}

TBR=rmcilroy@chromium.org
BUG=NONE

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

This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.

This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
  instruction.
* Lookup itself is naive in that it just returns the first code object
  for which (next_code_obj_addr > pc). It does not check that pc is
  actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
  at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
  but with the wrong code object.

This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.

BUG=v8:5311

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

Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f

Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5

Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3

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

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

Fixes the MIPS big-endian build after https://codereview.chromium.org/2276733002/ .

BUG=

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

  port 56429fc1 (r38978)

  original commit message:
  Introduced MachineType::TaggedSigned() and TaggedPointer().

  The idea is to quit using the representational dimension of Type, and
  instead encode this information in the MachineRepresentation (itself
  lightly wrapped in MachineType, along with MachineSemantic).

  There are three parts to the whole change:

  1) Places that set the machine representation - constant nodes, loads nad
     stores, global object and native context specialization.

  2) Places that propagate type/representation - this is representation
     inference (aka simplified lowering). At the end of this process we
     expect to have a MachineRepresentation for every node. An interesting
     part of this is phi merging.

  3) Places that examine representation - WriteBarrier elimination does this.
     Currently it's looking at the Type representation dimension, but as
     a part of this change (or in a soon-to-follow change) it can simply
     examine the MachineRepresentation.

BUG=

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

  port 1915762c (r38968)

  original commit message:
  These JavaScript operators were special hacks to ensure that we always
  operate on Smis for the magic for-in index variable, but this never
  really worked in the OSR case, because the OsrValue for the index
  variable didn't have the proper information (that we have for the
  JSForInPrepare in the non-OSR case).

  Now that we have loop induction variable analysis and binary operation
  hints, we can just use JSLessThan and JSAdd instead with appropriate
  Smi hints, which handle the OSR case by inserting Smi checks (that are
  always true). Thanks to OSR deconstruction and loop peeling these Smi
  checks will be hoisted so they don't hurt the OSR case too much.

  Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
  we have to lower it to JSLessThan to get the loop induction variable
  goodness.

BUG=

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

TBR=machenbach@chromium.org
BUG=chromium:635798,chromium:638295

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

This unblocks moving off having to hold on to a compiled module
template.

Once we don't have the template, when we have a single instance, the
instance and wasm module share the same compiled code. We will want
to clear that code off instance-specific stuff, when the instance is
unreferenced and should be GC-ed (stuff like the instance heap, for
instance). However, the deopt data will maintain a strong reference,
blocking the GC: the module object strongly references the compiled
code, which strongly references the instance object through the deopt
data.

This change addresses that by making that last reference weak.

BUG=v8:5316

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

BUG=None
TEST=None
R=mtrofin@chromium.org

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

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

This adds:
* A script (tools/update-wasm-fuzzers.sh), which creates a new fuzzing seed
  corpus and uploads to google storage (you must have the right credentials).
* A new pair of DEPS entries to pull in the current version of the corpus
  based on a checked in pair of hash files.

BUG=None
TEST=None
R=ahaas@chromium.org,kcc@chromium.org,mvstanton@chromium.org

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

Tail calls don't make sense from async functions and generators, as
each activation of these functions needs to make a new, distnict,
non-reused generator object. These tail calls are not required per
spec. This patch disables both syntactic and implicit tail calls
in async functions and generators.

R=neis
BUG=v8:5301,chromium:639270

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

V8 can use this metter to better estimate the amount of work that is still to be
done by the embedder. Supposed to be used to decide whether incremental marking
should be finalized or not.

BUG=chromium:468240
R=ulan@chromium.org

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

The format of this is a little strange, and has to do with the previous
implementation maintaining a "stack" of objects as it works. As a result,
the format writes the array buffer before giving any hint that the reason
for doing so is to obtain a view wrapping it. Handling this without creating
an explicit on-heap stack requires checking whether the next tag is 'V'
after obtaining an array buffer.

BUG=chromium:148757

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

The new fuzzer constructs a dummy module header and uses the fuzzer
data only as function code.

R=titzer@chromium.org, jochen@chromium.org

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

Add comments to make it easier to browse the HTML documentation generated with Doxygen.

BUG=v8:5260

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

These DCHECKs are executed when a wasm module is instantiated. However,
invalid load/store offsets should trigger runtime traps, not
instantiation-time errors.

R=titzer@chromium.org

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