For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.

R=yangguo@chromium.org
BUG=v8:5400

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

  port df981a9f (r40577)

  original commit message:
  The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
  conversion (except for the uses in HBranch and HCompareHoleAndBranch,
  which were confusing and useless anyways), so fix the naming to match
  that.

  Also properly integrate the handling of this flag with the existing
  truncation analysis that is run as part of the representation changes
  phase (i.e. where we already deal with truncating to int32 and smi).

  This is done in preparation of allowing Crankshaft to handle any kind
  of Oddball in the ToNumber truncation, instead of just undefined for
  truncation ToNumber and undefined or boolean for ToInt32. It also helps
  to make Crankshaft somewhat more compatible with the (saner)
  implementation in TurboFan.

BUG=

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

R=titzer@chromium.org,binji@chromium.org
BUG=v8:4614

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

BUG=657568
TEST=Manually, see bug report

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

This is a poor-man's solution to trigger page interactions.

BUG=

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

LOG=N
BUG=v8:4124

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

Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).

The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.

Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):

List type                       Zone memory used   Time taken
-----------------------------------------------------------------------
Zone array (for comparison)     131072 B

Ideally initialized ZoneList    131088 B           0.062ms

ChunkZoneList                   134744 B           0.052ms <--new thing

ZoneDeque                       141744 B

ZoneLinkedList                  393264 B

Initially empty ZoneList        524168 B           0.171ms <--right now

ChunkZoneList only push_front   524320 B

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

BUG=chromium:575167, v8:5507

R=rossberg@chromium.org,bradnelson@chromium.org
CC=ahaas@chromium.org

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

R=ahaas@chromium.org,rossberg@chromium.org,binji@chromium.org,bradnelson@chromium.org
BUG=chromium:575167, chromium:659591

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

If there is no stack trace (which happens), then at least print the
location of the message.

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

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

Turbofan requires a different tuning when compared to crankshaft. Crankshaft
typically has faster compilation times when compared to turbofan. Hence,
added a new parameter, so that crankshaft and turbofan can be tuned
independently.

OSRing too soon is not good for performance, especially for sunspider
benchmarks. Since they are really small functions and optimizing them is
more expensive than just executing unoptimized code. Tuning the code size
threshold of the functions that can be OSRed from ignition.

BUG=v8:4280,chromium:659111

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

- Modifies RegisterConfiguration to specify complex aliasing on ARM 32.
- Modifies RegisterAllocator to consider aliasing.
- Modifies ParallelMove::PrepareInsertAfter to handle aliasing.
- Modifies GapResolver to split wider register moves when interference
with smaller moves is detected.
- Modifies MoveOptimizer to handle aliasing.
- Adds ARM 32 macro-assembler pseudo move instructions to handle cases where
  split moves don't correspond to actual s-registers.
- Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of
  different widths, and moves involving pseudo-s-registers.
- Adds unit tests for FP operand interference checking and PrepareInsertAfter.
- Adds more tests of FP for the move optimizer and register allocator.

LOG=N
BUG=v8:4124

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

Just stumbled across this while doing
https://codereview.chromium.org/2457433002/

R=mstarzinger@chromium.org

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

Removes the need for a CanonicalHandleScope for parsing and renumbering
phases when using Ignition. Since AST strings are canonicalized by the
AST value factory, we only need to make sure we use the same canonical
handles for any other handles we add to the bytecode generator.

This avoids a regression when enabling Ignition for all Turbofan code, and
improves CodeLoad on for Ignition by about 5%.

BUG=v8:4280

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

For instance, when an import cannot be resolved, actually
point at the corresponding import statement.

BUG=v8:1569

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

Port df981a9f

Original commit message:

    The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
    conversion (except for the uses in HBranch and HCompareHoleAndBranch,
    which were confusing and useless anyways), so fix the naming to match
    that.

    Also properly integrate the handling of this flag with the existing
    truncation analysis that is run as part of the representation changes
    phase (i.e. where we already deal with truncating to int32 and smi).

    This is done in preparation of allowing Crankshaft to handle any kind
    of Oddball in the ToNumber truncation, instead of just undefined for
    truncation ToNumber and undefined or boolean for ToInt32. It also helps
    to make Crankshaft somewhat more compatible with the (saner)
    implementation in TurboFan.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

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

For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.

TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.

R=yangguo@chromium.org
BUG=chromium:659475

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

RejectPromise is always called on a pending promise making this a redundant check.

BUG=v8:5343

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

The TurboFan backends currently don't support tail-calls to CPP builtins
because the semantics of kJavaScriptCallArgCountRegister has different
semantics for stub call descriptors versus JavaScript call descriptors.
This is actually a short-coming of the backends and follow-up work will
make the backends more robust in that regard to fail hard on unsupported
constructs like that. This just disables the lowering creating such a
tail-call.

R=bmeurer@chromium.org
BUG=chromium:658691
TEST=mjsunit/regress/regress-crbug-658691

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

This patch replaces it with calls to the runtime function and PromiseSet.

This allows us to move PromiseReject to C++ without regressions.

BUG=v8:5343

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

Revert of [heap] Uncommit marking deque in concurrent task. (patchset #7 id:120001 of https://codereview.chromium.org/2442443003/ )

Reason for revert:
Seems to break the world, e.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/14118

Original issue's description:
> [heap] Uncommit marking deque in concurrent task.
>
> BUG=

TBR=mlippautz@chromium.org,ulan@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/2454693002
Cr-Commit-Position: refs/heads/master@{#40588}

R=jochen@chromium.org
NOTRY=true
BUG=

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

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

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

BUG=

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

R=adamk@chromium.org
BUG=

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

The tail-call operator for invoking a JSFunction object from within stub
code has been dead for a while and untested by now. This removes support
for such a construct.

R=bmeurer@chromium.org

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

Revert of [compiler] Properly validate stable map assumption for globals. (patchset #3 id:40001 of https://codereview.chromium.org/2444233004/ )

Reason for revert:
Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789

Original issue's description:
> [compiler] Properly validate stable map assumption for globals.
>
> For global object property cells, we did not check that the map on the
> previous object is still the same for which we actually optimized. So
> the optimized code was not in sync with the actual state of the property
> cell. When loading from such a global object property cell, Crankshaft
> optimizes away any map checks (based on the stable map assumption),
> leading to arbitrary memory access in the worst case.
>
> TurboFan has the same bug for stores, but is safe on loads because we
> do appropriate map checks there. However mixing TurboFan and Crankshaft
> still exposes the bug.
>
> R=yangguo@chromium.org
> BUG=chromium:659475

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

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

BUG=

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

The original reason for the extra output on windows is
obsolete since a while. Now the extra output just spams
the logs and causes traffic.

BUG=chromium:485932

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

Native setters (see AccessorInfo in accessors.h) didn't have the ability
to return a result value. As a consequence of this, for instance, Reflect.set
on the length property of arrays had the wrong behavior:

var y = [];
Object.defineProperty(y, 0, {value: 42, configurable: false})
Reflect.set(y, 'length', 0)

The Reflect.set call used to return true. Now it returns false as
required by the spec.

BUG=v8:5401

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

For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.

TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.

R=yangguo@chromium.org
BUG=chromium:659475

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

The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.

Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).

This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.

R=yangguo@chromium.org
BUG=v8:5400

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

Fix failing assertions in the CodeStubAssembler that cause Object.create(null,
global) fail.
Drive-by-fix: convert some Assert to CSA_ASSERT.

BUG=chromium:657692

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

All uses of NeanderObject have been replaced by FixedArrays.

BUG=

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

A GC might cause the just created dictionary object to have an invalid backing
store, which breaks heap verification.

BUG=chromium:659088

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

For Math builtins that likely yield double results, i.e. Math.sin,
Math.cos and friends, don't bother trying to canonicalize the result
to Smi. The rationale behind this is that other parts of V8 use the
HeapNumber representation as a hint to assume that certain values
should be represented as double (i.e. for the array elements kind
and for double field tracking). This way the chance that we make
the ideal decision early on is better.

For Math.abs we establish the contract that if the input value is a
Smi, then we try hard to return a Smi (doesn't work for minimal Smi
value), otherwise we preserve the HeapNumberness of the input.

Same for the generic Add, Subtract, Multiply, etc. code stubs.

R=yangguo@chromium.org

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

BUG=chromium:658426
R=ahaas@chromium.org,titzer@chromium.org,gdeepti@chromium.org

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

Simple "Print" API for the compiler graph.

BUG=

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

This causes a 3.1% regression because we unconditionally call out to a
runtime function.

This patch refactors out most of EnqueuePromiseReactionJob
runtime function into a separate function.

BUG=v8:5343

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

This reverts commit 59fb0956.

BUG=chromium:658718

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