BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1413703007

Cr-Commit-Position: refs/heads/master@{#31604}

Up until now, if one wanted to specify an explicit stack location                                                                                                                                                                                                or register as an operand for an instruction, it had to also be
explicitly associated with a virtual register as a so-called
FixedRegister or FixedStackSlot.

For the implementation of tail calls, the plan is to use the gap
resolver needs to shuffle stack locations from the caller to the
tail-called callee. In order to do this, it must be possible to
explicitly address operand locations on the stack that are not
associated with virtual registers.

This CL introduces ExplictOperands, which can specify a specific
register or stack location that is not associated with virtual
register. This will allow tail calls to specify the target
locations for the necessary stack moves in the gap for the tail
call without the core register allocation having to know about
the target of the stack moves at all.

In the process this CL:
* creates a new Operand kind, ExplicitOperand, with which
  instructions can specify register and stack slots without an
  associated virtual register.
* creates a LocationOperand class from which AllocatedOperand and
  ExplicitOperand are derived and provides a common interface to
  get Register, DoubleRegister and spill slot information.
* removes RegisterOperand, DoubleRegisterOperand,
  StackSlotOperand and DoubleStackSlotOperand, they are subsumed
  by LocationOperand.
* addresses a cleanup TODO in AllocatedOperand to reduce the
  redundancy of AllocatedOperand::Kind by using machine_type() to
  determine if an operand corresponds to a general purpose or
  double register.

BUG=v8:4076
LOG=n

Review URL: https://codereview.chromium.org/1389373002

Cr-Commit-Position: refs/heads/master@{#31603}

Review URL: https://codereview.chromium.org/1418423007

Cr-Commit-Position: refs/heads/master@{#31602}

Cr-Commit-Position: refs/heads/master@{#31601}

BUG=chromium:490559
LOG=NO

Review URL: https://codereview.chromium.org/1420363004

Cr-Commit-Position: refs/heads/master@{#31600}

Adds a scavenge GC pass that collects unmodified references instead of
processing object groups. This mode can be controlled by setting
FLAG_scavenge_reclaim_unmodified_objects. By default this is turned off.
Also, modified a test case to suit the handle the new GC pass.

BUG=v8:4421
LOG=N

Review URL: https://codereview.chromium.org/1410593005

Cr-Commit-Position: refs/heads/master@{#31599}

This introduces a JSConvertReceiver operator to model the implicit
conversion of receiver values for sloppy callees. It is used by the
JSInliner for now, but can also be used to model direction function
calls that bypass call stubs.

Also note that a hint is passed to said operator whenever the source
structure constrains the receiver value type. This hint allows for
optimizations in the lowering of the operator.

The underlying specification in ES6, section 9.2.1.2 is the basis for
this implementation.

R=bmeurer@chromium.org
TEST=mjsunit/compiler/receiver-conversion
BUG=v8:4493, v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1412223015

Cr-Commit-Position: refs/heads/master@{#31598}

BUG=

Review URL: https://codereview.chromium.org/1410223007

Cr-Commit-Position: refs/heads/master@{#31597}

Change CompareNilIC to return true/false instead of 1/0, and use the
CompareNilICStub in TurboFan for abstract equality with null/undefined.
This way we don't always run into the %Equals runtime fallback when
comparing objects with null/undefined.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1417503008

Cr-Commit-Position: refs/heads/master@{#31596}

R=jochen
BUG=

Review URL: https://codereview.chromium.org/1424793004

Cr-Commit-Position: refs/heads/master@{#31595}

Currently we still (mis)used some machine operators in typed lowering
(namely Word32Or, Word32Xor and Word32And). But these operators are
"polymorphic" in the signedness of their inputs and output, hence the
representation selection (and thereby simplified lowering) was unable to
figure out whether a bitwise operation that was seen would produce an
unsigned or a signed result. If such nodes also have frame state uses,
the only safe choice was float64, which was not only a lot less ideal,
but also the main cause of the for-in related deoptimizer loops.

Adding dedicated NumberBitwiseOr, NumberBitwiseAnd and NumberBitwiseXor
simplified operators not only gives us precise (and correct) typing for
the bitwise operations, but also allows us to actually verify the graph
properly after typed lowering.

Drive-by-fix: Remove the double-to-smi magic from the Deoptimizer, which
is responsible for various deopt-loops in TurboFan, and is no longer
needed with the addition of the NumberBitwise operators.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1422213002

Cr-Commit-Position: refs/heads/master@{#31594}

With ES6 21.2.5.8, step 13, we no longer have to keep up the illusion
that matching and calling replace function is interleaved. This is
observable through unspec'ed static properties such as RegExp.$1.

Last match info not working yet.

R=littledan@chromium.org

Review URL: https://codereview.chromium.org/1418703003

Cr-Commit-Position: refs/heads/master@{#31593}

       The test mjsunit/regress/regress-sqrt compares the result of Math.sqrt function
       when using full-compiler and turbofan/crankshaft compiler seperately. But according
       to glibc bug fixing(https://sourceware.org/bugzilla/show_bug.cgi?id=14032). The
       glibc implementation of std::sqrt() (It is invoked in the generated code when
       full-compiler is used.) will change since glibc 2.19.

       In order to keep consistence of Math.sqrt translation in turbofan compiler
       and the pass of mjsunit/regress/regress-sqrt. we translate the Math.sqrt func
       according to the same fix in glibc change.  If the GLIBC version >=2.19, we will
       set the precision to Double. (the original is extended-double).

       This fix is to fix the same issue in https://codereview.chromium.org/606403002 for
       crankshaft. This fix may be ported for crankshaft too.

BUG=

Review URL: https://codereview.chromium.org/1425763002

Cr-Commit-Position: refs/heads/master@{#31592}

Abstract equality of boolean values reduces to reference equality.

R=verwaest@chromium.org

Review URL: https://codereview.chromium.org/1425773002

Cr-Commit-Position: refs/heads/master@{#31591}

Revert of Check that array length stays a safe integer in Array.prototype.push (patchset #7 id:120001 of https://codereview.chromium.org/1428483002/ )

Reason for revert:
Caused for-in-opt test to fail

Original issue's description:
> Check that array length stays a safe integer in Array.prototype.push
>
> This patch adds a check in Array.prototype.push to assert that the new
> length does not become greater than 2**53-1. Such a length would be
> dangerous because integer arithmetic becomes imprecise after the
> boundary. The check is also required by a test262 test.
>
> R=adamk
> LOG=Y
> BUG=v8:3087
>
> Committed: https://crrev.com/e68adf4548dd101dc08fcbff14444152fb1b7fe7
> Cr-Commit-Position: refs/heads/master@{#31588}

TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3087

Review URL: https://codereview.chromium.org/1418093007

Cr-Commit-Position: refs/heads/master@{#31590}

Reduce code duplication somewhat restructure the code to make
it easier to spot the code paths for the different property
cell types.

R=jarin@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1413383004

Cr-Commit-Position: refs/heads/master@{#31589}

This patch adds a check in Array.prototype.push to assert that the new
length does not become greater than 2**53-1. Such a length would be
dangerous because integer arithmetic becomes imprecise after the
boundary. The check is also required by a test262 test.

R=adamk
LOG=Y
BUG=v8:3087

Review URL: https://codereview.chromium.org/1428483002

Cr-Commit-Position: refs/heads/master@{#31588}

- inner_scope_uses_arguments_ was completely unused
- The public accessor for contains_with() was not called
- inside_with() had helper methods on Parser and PatternRewriter, but was
  only called in one place.

Review URL: https://codereview.chromium.org/1409253007

Cr-Commit-Position: refs/heads/master@{#31587}

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1423923003

Cr-Commit-Position: refs/heads/master@{#31586}

Cr-Commit-Position: refs/heads/master@{#31585}

Adds support for loading from and storing to outer context
variables. Also adds support for declaring functions on contexts and
locals. Finally, fixes a couple of issues with StaContextSlot where
we weren't emitting the write barrier and therefore would crash in the
GC.

Also added code so that --print-bytecode will output the
function name before the bytecodes, and replaces MachineType with StoreRepresentation in RawMachineAssembler::Store and updates tests.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1425633002

Cr-Commit-Position: refs/heads/master@{#31584}

Fix additional cases where the AIX compiler reports that a variable
may be used uninitialized.

R=danno@chromium.org, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1420273006

Cr-Commit-Position: refs/heads/master@{#31583}

The upper 32-bits of the FP compare register are undefined in
the float32 case. The compare instruction returns all 1's or
all 0's, so just use the LS bit.

Remove unnecessary use of 'at' reg. Change mips32 for consistency,
but it did not have the bug.

TEST=mjsunit/asm/embenchen/box2d (r6)
BUG=

Review URL: https://codereview.chromium.org/1425603002

Cr-Commit-Position: refs/heads/master@{#31582}

https://codereview.chromium.org/1412123009/ )"

This reverts commit 5308a999.

BUG=chromium:546416
LOG=N

Review URL: https://codereview.chromium.org/1424653004

Cr-Commit-Position: refs/heads/master@{#31581}

LOG=N
BUG=v8:4026

Review URL: https://codereview.chromium.org/1416873008

Cr-Commit-Position: refs/heads/master@{#31580}

R=hpayer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=chromium:542823
LOG=n

Review URL: https://codereview.chromium.org/1415143004

Cr-Commit-Position: refs/heads/master@{#31579}

along with follow-up fixes:

- "introduce LookupIterator::Restart() and use it"
- "always reset the LookupIterator before storing"
- "API-style accessors can throw, check for that"

Revert reason was fixed in Chromium: https://codereview.chromium.org/1415453003/

This reverts the following commits:
0188aead
984f8af8
dc9d2c16
a0f5d499

Review URL: https://codereview.chromium.org/1424503003

Cr-Commit-Position: refs/heads/master@{#31578}

Drive-by-fix: Move IC::GetRootConstructor to Map::GetConstructorFunction,
so we can use that in the ICs, Crankshaft and Turbofan.

R=jarin@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1416493007

Cr-Commit-Position: refs/heads/master@{#31577}

R=bmeurer@chromium.org

Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755
Cr-Commit-Position: refs/heads/master@{#31566}

Review URL: https://codereview.chromium.org/1423833003

Cr-Commit-Position: refs/heads/master@{#31576}

Adds support and tests for conditional (ternary) expressions.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1417053004

Cr-Commit-Position: refs/heads/master@{#31575}

Revert of [heap] remove unneeded call to LowerInlineAllocationLimit (patchset #2 id:20001 of https://codereview.chromium.org/1390013002/ )

Reason for revert:
Causes memory footprint regression: https://code.google.com/p/chromium/issues/detail?id=541135

The intent of the code here was to advance the inline allocation limit without counting the allocated memory towards a step. Calling LowerInlineAllocationLimit this way is a blunt way of doing it, but it works.

At this point it is simplest to revert this CL. My follow-on CL (https://codereview.chromium.org/1404523002/) can address the 'bluntness' of calling LowerInlineAllocationLimit from here along with leaving a comment about the intent.

revert_cq: 1
revert_reason_textarea: Causes memory footprint regression: https://code.google.com/p/chromium/issues/detail?id=541135

The intent of the code here was to advance the inline allocation limit without counting the allocated memory towards a step. Calling LowerInlineAllocationLimit this way is a blunt way of doing it, but it works.

At this point it is simplest to revert this CL. My follow-on CL (https://codereview.chromium.org/1404523002/) can address the 'bluntness' of calling LowerInlineAllocationLimit from here along with leaving a comment about the intent.

Original issue's description:
> [heap] remove unneeded call to LowerInlineAllocationLimit
>
> Calling LowerInlineAllocationLimit from the bottom of Heap::Scavenge seems to be
> a no-op.
>
>   new_space_.LowerInlineAllocationLimit(
>       new_space_.inline_allocation_limit_step());
>
> LowerInlineAllocatoinLimit does the following things:
>
> 1. Set the inline_allocation_limit_step_ to the passed in value. No-op.
> 2. Calls UpdateInlineAllocationLimit(0). This is unnecessary here as it has
>    already been called when new_space_.ResetAllocationInfo was called above.
> 3. Sets top_on_previous_step_. This again is unnecessary as it gets reached by
>    ResetAllocationInfo as well.
>
> BUG=
> R=hpayer@chromium.org,ulan@chromium.org
>
> Committed: https://crrev.com/9f8e8b835a468b1622c5350a01a97bc32c5b2fb7
> Cr-Commit-Position: refs/heads/master@{#31156}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:541135
LOG=n

Review URL: https://codereview.chromium.org/1405043005

Cr-Commit-Position: refs/heads/master@{#31574}

BUG=

Review URL: https://codereview.chromium.org/1422973002

Cr-Commit-Position: refs/heads/master@{#31573}

R=bmeurer@chromium.org
TEST=mjsunit/tools/profviz
BUG=v8:4493
LOG=n

Review URL: https://codereview.chromium.org/1419333003

Cr-Commit-Position: refs/heads/master@{#31572}

Revert of Assume that ReportFailedAccessCheck always schedules an exception. (patchset #1 id:1 of https://codereview.chromium.org/1420413002/ )

Reason for revert:
[Sheriff] Crashes in layout tests:
http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/2539

#
# Fatal error in , line 0
# unreachable code
#

Original issue's description:
> Assume that ReportFailedAccessCheck always schedules an exception.
>
> R=verwaest@chromium.org
> BUG=
>
> Committed: https://crrev.com/effe76ad25c23bfd8be447930bd5d5126b1c9096
> Cr-Commit-Position: refs/heads/master@{#31560}

TBR=verwaest@chromium.org,neis@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1424703002

Cr-Commit-Position: refs/heads/master@{#31571}

Revert of Canonicalize handles for optimized compilation. (patchset #1 id:1 of https://codereview.chromium.org/1423833003/ )

Reason for revert:
GC stress failure on ia32 optdebug:

/tmp/runfswAKT/out/Debug/d8 --test --random-seed=-1536184370 --turbo --always-opt --nohard-abort --nodead-code-elimination --nofold-constants --enable-slow-asserts --debug-code --verify-heap --stack-size=46 /tmp/runfswAKT/test/mjsunit/mjsunit.js /tmp/runfswAKT/test/mjsunit/regress/regress-1132.js --gc-interval=500 --stress-compaction --concurrent-recompilation-queue-length=64 --concurrent-recompilation-delay=500 --concurrent-recompilation

Run #1
Exit code: -6
Result: FAIL
Expected outcomes: PASS
Duration: 00:06:279

Stderr:

#
# Fatal error in ../../src/hashmap.h, line 248
# Check failed: base::bits::IsPowerOfTwo32(capacity_).
#

==== C stack trace ===============================

Original issue's description:
> Canonicalize handles for optimized compilation.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755
> Cr-Commit-Position: refs/heads/master@{#31566}

TBR=jochen@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1417013007

Cr-Commit-Position: refs/heads/master@{#31570}

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1425643002

Cr-Commit-Position: refs/heads/master@{#31569}

Turn the DCHECK in the Typer into a CHECK, and don't silently continue
in production. This way we know that we will always make progress
towards the fixpoint.

R=jarin@chromium.org, rossberg@chromium.org

Review URL: https://codereview.chromium.org/1422893003

Cr-Commit-Position: refs/heads/master@{#31568}

Introduce new typing rules for LoadField[Map], which try to take into
account stable map information if the object either has type Constant or
type Class. If the map of the object is stable but can transition we
have to introduce a code dependency in the Typer to make sure that the
information (the Constant type we infer for LoadField[Map]) is valid
(and stays valid).

This also settles the policy for depending on map stability: The
definition can introduce any number of maps, without having to pay
attention to stability (i.e. you can always use Type::Class to introduce
a map that is propagated along the value edges), and the use site is
responsible for checking that the type information is valid before using
it. I.e. if you use stable map information, you'll have to add a
stability dependency (or make sure the map cannot transition).

Drive-by-improvement: Add ReferenceEqualTyper which takes input types
into account for improved constant folding.

Drive-by-fix: Apply policy mentioned above to JSNativeContextSpecialization.

R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1410953006

Cr-Commit-Position: refs/heads/master@{#31567}

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1423833003

Cr-Commit-Position: refs/heads/master@{#31566}

From the Google C++ style guide: "You may not use a using-directive to
make all names from a namespace available". This would be covered by
presubmit linter checks if build/namespaces were not blacklisted.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1410073004

Cr-Commit-Position: refs/heads/master@{#31565}