This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.

R=mvstanton@chromium.org

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

R=jarin@chromium.org
BUG=chromium:659967

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

This patch refactors most of FulfillPromise runtime call out to a separate
function so that we can to it from PromiseReject runtime call.

This patch adds a PromiseStatus enum.

BUG=v8:5343

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

This reverts commit 35e4a03f.

BUG=

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

We used to point elsewhere, for instance the right-hand-side of an assignment.

Small limitation: Since variable proxies only have a start position, not an end
position, the best we can do is point at the first character.  (We cannot rely
on the scanner's last token position because Declare may be called long after
the variable has been scanned.)

R=adamk@chromium.org
BUG=v8:5572

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

Reuses (and renames) the SFI "mark for optimization" flag to also permit
marking for baseline recompilation. The flag now represents a "tier up"
request, and CompileLazy can get baseline code as well as optimized
code.

BUG=v8:5512

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

BUG=

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

This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.

I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.

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

'[...] accessor properties who have the attributes { [[Enumerable]]:
false, [[Configurable]]: true } [...]'

BUG=v8:5566

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

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}