Trampolines are generated when the value of pc_offset is greater than
next_buffer_check_ (attribute from Assembler class). This value
shouldn't be incremented in bind_to() method when internal reference
label is bound, because it is not decremented when the switch table is
generated (dd() method from Assemler class).

This patch fixes this problem. Regression test are also included for
mips and mips64 arch.

BUG=

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

The loop for non-"static" properties is no longer needed in
full-codegen since all computed property
names in object literals go through Ignition first.

BUG=v8:5657

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

Top level SharedFunctionInfos will end up in a scripts SFI list, but
eval'd SFIs shouldn't. Separate IDs will allow for adding a
corresponding DCHECK.

BUG=v8:5589
R=marja@chromium.org

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

This fixes the existing workaround in {BytecodeGraphBuilder} where the
number of elements in an array literal is unknown just from the bytecode
alone and needs to be deduced from the constant elements.

Note that this is just a quick fix to prevent calling the fast-clone
stub for boilerplates that are too big to fit on a regular page. In the
long run we need something more solid here.

R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-669850
BUG=chromium:669850

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

  Currently In LCodeGen::DoWrapReceiver(), the x87 jitted code's size for debug mode between label's define and bind
  exceeds 128 bytes whether FLAG_deopt_every_n_times is set or not.

  So always use Label:kFar as label distance in LCodeGen::DoWrapReceiver() for debug mode.

  This CL also unify the label's distance value to avoid potential bugs caused by unconsistent distance value usage
  for the same label when DeoptEveryNTimes() return true.

BUG=

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

We can skip RegExpResult construction on the fast path for several functions to
be more efficient.

BUG=v8:5330,v8:5674

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

Bonus: fixed a couple of places where 32-bit comparison was used.

BUG=

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

Allow a function to be exported multiple times in a asm.js
module.
Remarkably, this had not been working before.

BUG=670057
R=titzer@chromium.org

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

Unfortunately we have to split this up into two cases: those with exactly one spread argument as the final argument, and all others, due to any side-effects of evaluation being visible.

This is in preparation for a new bytecode which handles super calls.

BUG=v8:5659

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

This refactors portions of exec into a new function without RegExpResult
construction, which will be used in the future by test, @@match, and @@search
fast paths.

Unnecessary ToString and ToLength calls as well as repeated map checks were
removed.

BUG=v8:5339

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

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

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

This ensure that all inline allocations generated by {JSCreateLowering}
will fit into a regular heap page. Allocations targeting LO-space must
be done via a slower runtime call.

R=bmeurer@chromium.org
BUG=chromium:669850

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

The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic, and added unit test cases.

R=ishell@chromium.org, titzer@chromium.org
CC=ahaas@chromium.org, bmeurer@chromium.org

Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
Review-Url: https://codereview.chromium.org/2526783002
Cr-Original-Commit-Position: refs/heads/master@{#41275}
Cr-Commit-Position: refs/heads/master@{#41411}

BUG=chromium:603131
LOG=y

Committed: https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac
Review-Url: https://codereview.chromium.org/2533813002
Cr-Original-Commit-Position: refs/heads/master@{#41407}
Cr-Commit-Position: refs/heads/master@{#41410}

Revert of [build] Use MSVS 2015 by default. (patchset #5 id:80001 of https://codereview.chromium.org/2533813002/ )

Reason for revert:
Breaks CI dbg builder:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug%20builder/builds/13817

Original issue's description:
> [build] Use MSVS 2015 by default.
>
> BUG=chromium:603131
> LOG=y
>
> Committed: https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac
> Cr-Commit-Position: refs/heads/master@{#41407}

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

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

This shows around a 2.2x speedup compared to the old JS implementation (and
3.5x compared to CPP) for the fast path.

Adds ToUint32 to CodeStubAssembler.

BUG=v8:5339

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

BUG=chromium:603131
LOG=y

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

R=franzih@chromium.org, kozyatinskiy@chromium.org, machenbach@chromium.org
BUG=

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

This code is no longer used in full-codegen since all computed property
names in object literals go through Ignition first.

BUG=v8:5657

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4e4ff82..ac12d5e

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/991f459..102c163

Rolling v8/third_party/android_tools: https://chromium.googlesource.com/android_tools/+log/811a2c3..b43a6a2

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/2dd86f1..582ccd4

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f81598c..ccd4a12

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

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

Incremental parsing of asm.js means we can see function tables that
are unused in the AsmWasmBuilder before they've been initialized.

BUG=669899
R=aseemgarg@chromium.org

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

This roll includes:
  - [inspector_protocol] always use weak pointer in DispatcherImpl::{command.name} [1]

[1] https://codereview.chromium.org/2545613002/

BUG=chromium:668358
TBR=dgozman@chromium.org

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

If we just call CreateDebugInfo in GetPossibleBreakpoints then we won't call PrepareFunctionForBreakPoints and won't be able to step into this function or pause at breakpoint inside.

BUG=v8:5695
R=dgozman@chromium.org,yangguo@chromium.org

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

During codegen, we build a list mapping protected instructions to their
associated landing pads. This will ultimately by used by the signal handler to
recover from out of bounds faults and throw a JS exception.

This is mostly pulled from my larger in-progress CL at
https://codereview.chromium.org/2371833007/.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

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

R=jarin@chromium.org

BUG=v8:668517

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

This is necessary for signal-based out of bounds handling in WebAssembly.

Adds a ProtectedStore instruction that is analogous to the previously added
ProtectedLoad instruction. Rather than using bounds checks, ProtectedStore emits
an out of line section of code that throws a JavaScript exception and provides
the necessary metadata for a signal handler to be able to find the out of line
code.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

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

Attempt to fix or get insight into failing vswp test on V8 ARM bot.

LOG=N
BUG=

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

The "writable" property descriptor may legally change during the call to
AnythingToArrayLength(). This change needs to be honoured before calling
JSArray::SetLength(). The change is only honoured when the "length"
property was previously writable, so that changes during a call to
DefineOwnPropertyIgnoreAttributes() is ignored.

BUG=v8:5688
R=cbruni@chromium.org, verwaest@chromium.org, jkummerow@chromium.org

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

BUG=

R=jyan@ca.ibm.com,joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,bjaideep@ca.ibm.com

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

Before, we were treating objects with the builtin ArrayValues iterator
method as array-like, where the iterator would iterate through to the
full length of the object.

This optimization was not sound, because it does not ensure that the
next method hasn't been modified. Even if it hasn't been modified,
it's entirely possible to be modified during iteration. Thus, this
optimization has been removed due to its observability.

BUG=v8:5699
R=littledan@chromium.org, cbruni@chromium.org

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

This was causing more confusion than benefit, so we're removing it.

It's re-defined to empty for now, to avoid touching the ~100 files which
use it, we can remove it completely during a quiet period when it's less
likely to conflict with other work.

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

JS operators always have an implicit context input, so just use that instead.

BUG=

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

This is an experiment to see the impact of the limit on OOM crashes.

BUG=chromium:667388

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

BUG=chromium:666947

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

BUG=chromium:669024

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

These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.

R=titzer@chromium.org
BUG=chromium:669518

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

JSFrameSpecialization depends on the layout of the frame and doesn't work
with interpreted frames. Disable it since it is only used for OSR from asmjs code, which shouldn't go through the bytecode graph builder in many cases.

BUG=669517

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

Also move them to a separate interface header to avoid having to include
parser.h so much

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

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

Remove redundant operands swap for compare operation.

BUG=

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

Defining the subclass within the loop significantly affects subsequent
test results. For instance, the Search benchmark is 50% slower if the
subclass is defined within the loop.

BUG=v8:5339

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