In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
  which is set in ComputeCallerState. The WASM frame uses this
  information to determine whether the callee frame is WASM_TO_JS, and
  whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}

Too many crashes in Canary.

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

The deserialization of the {Scope::asm_module} predicate relies on a
context being present for such modules. This ensures we always allocate
such a context, even in cases where no variables are allocated in it.

R=neis@chromium.org
TEST=cctest/test-parsing/AsmModuleFlag
BUG=v8:5653

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

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

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

Same idea as in the previous change. In addition, explicitly limited to non-aliased
registers, because the logic there needs to take account of, well, alias IDs. Left a
TODO for that part.

BUG=v8:5644

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/53448a6..50196c9

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/11d3d44..0b7222f

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/caccf42..53bdedc

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

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

This will be used in CSA to check if any promisehook is set.

-- Adds a is_promisehook_enabled_ field to the isolate and helper methods.
-- Adds this field to the ExternalReference table.
-- Adds a helper method to access this from CSA

Note -- this patch doesn't actually add the ability to attach the hook
yet.

BUG=v8:4643

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

  port 378b6b22 (r41554)

  original commit message:
  Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo.
  This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.

BUG=

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

R=adamk@chromium.org
BUG=

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

https://codereview.chromium.org/2405213002/ introduced FunctionTemplate::NewWithCache in src/api.cc, but used LOG_API(..., NewWithFastHandler)

BUG=667237

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

BUG=chromium:670683

R=titzer@chromium.org

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

When finding conflicts, there's no reason to keep looking for registers that are clearly
not going to be available to a candidate live range.

BUG=v8:5644

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

Revert of [wasm] Fix location for error in asm.js ToNumber conversion (patchset #5 id:80001 of https://codereview.chromium.org/2555243002/ )

Reason for revert:
gc-stress failures

Original issue's description:
> [wasm] Fix location for error in asm.js ToNumber conversion
>
> In the asm.js code translated to wasm, we call imported functions via a
> WASM_TO_JS stub, which first calls the function and then calls ToNumber
> on the return value. Exceptions can happen in both calls.
> We were only ever reporting the location of the function call, whereas
> asm.js code executed via turbofan reported the location of the type
> coercion operator ("+" on "+foo()" or "|" on "foo()|0").
>
> This CL implements the same behaviour for asm.js code translated to
> wasm. The following is changed:
> - the AsmWasmBuilder records the parent node when descending on a binary
>   operator (also "+foo()" is represented by a binary operation).
> - it stores not one location per call in the source position side
>   table, but two (one for the call, one for the parent which does the
>   type coercion).
> - the wasm compiler annotates the source positions "0" and "1" to the
>   two calls in the WASM_TO_JS wrapper (only if the module origin is
>   asm.js).
> - during stack trace generation (in the StackTraceIterator), when we
>   move from the WASM_TO_JS frame to the WASM frame, we remember at which
>   call inside the WASM_TO_JS wrapper we are, and encode this information
>   in the generated caller state, used for the WASM frame.
> - the same information is also stored in the FrameArray which is used
>   to reconstruct the stack trace later.
>
> R=titzer@chromium.org, bradnelson@chromium.org
> CC=jgruber@chromium.org
> BUG=v8:4203,v8:5724
>
> Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
> Cr-Commit-Position: refs/heads/master@{#41599}

TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4203,v8:5724

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

Now that SharedFunctionInfos have a unique ID (and the IDs are dense),
we can use them as an index into an array, instead of using a
WeakFixedArray where we have to do a linear scan.

Hooking up liveedit is a bit more involved, see
https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit
for an overview

BUG=v8:5589
R=verwaest@chromium.org,jgruber@chromium.org

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

In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- during stack trace generation (in the StackTraceIterator), when we
  move from the WASM_TO_JS frame to the WASM frame, we remember at which
  call inside the WASM_TO_JS wrapper we are, and encode this information
  in the generated caller state, used for the WASM frame.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

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

BUG=

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

Lowercase 1 character strings occur frequently in minified code. Add a
cache for them, so that we don't need to compute the hash + do the hash
table lookup for each occurrence.

BUG=

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

Fix 7a6f294f.

The first correction enables correct execution DoMathMinMax when two
input registers are the same register.
The second correction adds NOP instructions after branch instructions
in tests macro_float_minmaxf(32|64).

TEST=cctest/test-macro-assembler-mips[64]/macro_float_minmax_f32
     cctest/test-macro-assembler-mips[64]/macro_float_minmax_f64
     mjsunit/regress/math-min
BUG=

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

We have been assuming in several places that ContainsDot or ToInt32 is
sufficient to check a value is a valid double or int.
Refactoring all the checks to one place and making them cope with booleans
or other unexpected types being present.

BUG=672044
R=titzer@chromium.org

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

Use of eval in a function wraps it in a context.
This throws off assumptions not checked until later,
which is at odds with incremental validation and conversion.
Check that module parameters are PARAMETER location early.

BUG=672045
R=titzer@chromium.org

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

needs finalization and allocation limit is reached.

BUG=

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

BUG=chromium:648568, chromium:669920

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

https://github.com/ibmruntimes/v8/issues/27

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

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

BUG=

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

Wrap the liveness bitvectors from the bytecode liveness analysis with a
helper class, which makes the register/accumulator bits explicit.

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

Aside from the default snapshot, there is no need for additional context
snapshots to have the ability to replace the global proxy and global object
after deserialization. Changes include:
 - Changes to the API to better distinguish default context snapshot from
   additional context snapshots.
 - Disallow global handles when creating snapshots.
 - Allow extensions when creating snapshots.

This solves the issue of not being able to having accessors and interceptors on
the global object of contexts to be serialized.

R=jochen@chromium.org, peria@chromium.org
BUG=chromium:617892

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

R=jochen@chromium.org
BUG=chromium:617892

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

Drive-by-fix: support directly loading the results.json from chromeperf.

BUG=chromium:672024
NO_TRY=true

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

All accessor IC stubs now pass the verification.

BUG=

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

The patch was reverted due to a bug - we failed to evict OSR-optimized
code in the case where the SharedFunctionInfo OptimizedCodeMap was
empty/cleared.

Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.

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

BUG=v8:5723

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

This CL attempts to set the maybe-assigned flag for variables that are written
to as part of a destructuring or loop header.

For instance, in the following two cases we now mark x as maybe-assigned.

a) [x] = [1];
b) for (x of [1,2,3]) {};

There's more work to do here, this is just a first step.

R=adamk@chromium.org, mstarzinger@chromium.org
BUG=v8:5636

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

Using x&(x-1) to check for power of two masks usable at runtime
speeds up the life benchmark.

Borrowing this from SimplifiedLowering for the AsmJsRemS internal
wasm opcode.

Leaving this out for general wasm as we should be doing this optimization
in LLVM.

BUG=v8:4203
TEST=None
R=bmeurer@chromium.org

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

Speeds up some benchmarks that make heavy use of derived constructors.

BUG=chromium:672075

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

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

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

Currently when the number passed to TryNumberToSize is 1 << 64,
it gets away with a bug caused by rounding of mantissa.
Then the number will be casted to 0 and TryNumberToSize
will return true. This patch fix this by making the range check
more accurate.

BUG=v8:5712

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

R=adamk@chromium.org, mstarzinger@chromium.org
BUG=

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

BUG=672047
R=titzer@chromium.org

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

As of https://github.com/tc39/ecma262/commit/13906140a, the spec
now returns true when [[SetPrototypeOf]] is invoked with null
on a module namespace object.

R=neis@chromium.org
BUG=v8:1569

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

We were losing the stats for the first instance. Recording them
as soon as code objects are produced. This way, we have them available
for compile-only benchmarks.

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