port 9b12ec9a (r30919)

original commit message:

    This lowers JSCreateArgument nodes to call the ArgumentsAccessStub for
    help with materializing arguments objects when possible. Along the way
    this changes the calling convention of said stub to take parameters in
    registers instead of on the stack.

R=weiliang.lin@intel.com
BUG=

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

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

Since https://codereview.chromium.org/366103005 the promise tests null out
various globals, to ensure the promise implementation doesn’t itself rely
on functions patchable by monkeys.

Unfortunately, doing so breaks test assertion failures which rely on
those globals.

This isn’t the ideal solution, but does improve the current state.

R=littledan@chromium.org,domenic@chromium.org
LOG=N
BUG=

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

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

Once I improved byte accounting done for incremental mark in [1], there is some
code duplication that becomes apparent. This commit refactors the duplicated
code into a private method on NewSpace. This also makes it easy to add new
consumers of inline allocation steps in the future.

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

R=hpayer@chromium.org
BUG=

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

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

R=titzer@chromium.org

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

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

This lowers JSCreateArgument nodes to call the ArgumentsAccessStub for
help with materializing arguments objects when possible. Along the way
this changes the calling convention of said stub to take parameters in
registers instead of on the stack.

R=mvstanton@chromium.org

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

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

+ Add bytecodes for conditional and unconditional jumps.
+ Add bytecodes for test/compare operations.
+ Expose jumps in bytecode-array-builder and add BytecodeLabel class for
  identifying jump targets.
+ Add support for if..then...else in the bytecode-generator.
+ Implement jump bytecodes in the interpreter. Test/compare operations
  dependent on runtime call for comparisons.

BUG=v8:4280
LOG=N

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

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

NOTRY=true

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

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

This introduces the NodeProperties::ChangeOp helper which guards node
operator changes so that additional checking can be done without any
additional dependencies being pulled into the Node class. For now only
the input count is checked, but additional checking might follow.

R=jarin@chromium.org

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

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

BUG=

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

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

Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ )

Reason for revert:
Failures on greedy RegAlloc, Fuzzer

Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
>   so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
>   different platforms is now shared.
> * The list of allocatable registers on each platform is declared
>   as a list rather than implicitly via the register index <->
>   code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}

TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.

Some highlights of changes:

* TurboFan's RegisterConfiguration class moved to V8's top level
  so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
  different platforms is now shared.
* The list of allocatable registers on each platform is declared
  as a list rather than implicitly via the register index <->
  code mapping.

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

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

Refactor the StackFrameIterator::ComputeType() method to look up the code object (if any) before looking at the magic markers.

This will allow per-code-kind logic more easily in the future (e.g. for WASM).

BUG=

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

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

This patch checks the type of the lhs operand of a floating point
comparison for ARM, and commutes the operands if it is #0.0.  It allows
us to optimize a comparison with zero, as the vcmp instruction
accepts #0.0 as rhs operand.

Code before for "0.0 < 0.123":
------------------------------
movw ip, #29360
movt ip, #37224
movw r9, #31981
movt r9, #16319
vmov d0, ip, r9
mov ip, #0
vmov d1, ip, ip
vcmp.f64 d1, d0
vmrs APSR, FPSCR
bcc +12

Code after:
-----------
movw ip, #29360
movt ip, #37224
movw r9, #31981
movt r9, #16319
vmov d0, ip, r9
vcmp.f64 d0, #0.0
vmrs APSR, FPSCR
bgt +12

BUG=

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

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

Adds LdaGlobal bytecode and augments BytecodeGenerator to load globals for
global variables and function calls.

Modified TestBytecodeGenerator to add the ability to specify that a bytecode
operand has an unknown value (used so we don't need to figure out the slot
index of a global). Also added a helper which checks equality of BytecodeArray
with the expected snipptets.

Modified TestInterpreter to allow it to take snippets of JS and have the
BytecodeGenerator generate the bytecode rather than having to build a
BytecodeArray manually. This is used to enable the global tests.

BUG=v8:4280
LOG=N

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

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

Reduce operations of the form f64cmp(fp32to64(x), k) to f32cmp(x, k) when k
can be encoded as a 32-bit float.

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

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

port 8fe3ac07 (30902).

original commit message:

    There was already a bit on the Map named "function with prototype",
    which basically meant that the Map was a map for a JSFunction that could
    be used as a constructor. Now this CL generalizes that bit to
    IsConstructor, which says that whatever (Heap)Object you are looking at
    can be used as a constructor (i.e. the bit is also set for bound
    functions that can be used as constructors and proxies that have a
    [[Construct]] internal method).

    This way we have a single chokepoint for IsConstructor checking, which
    allows us to get rid of the various ways in which we tried to guess
    whether something could be used as a constructor or not.

    Drive-by-fix: Renamed IsConstructor on FunctionKind to
    IsClassConstructor to resolve the weird name clash, and the
    IsClassConstructor name also matches the spec.

BUG=

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

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

port 556b522a (r30883)

original commit message:

    We somehow try to push some stuff on the stack when we detect a stack
    overflow, that we don't need. Even worse we might access outside the
    valid stack bounds. Since we don't need this, it's gone.

BUG=

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

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

NOTRY=true

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

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

This patch explicitly names commuted conditions for floating point
comparisons, instead of relying on CommuteFlagsCondition.  Otherwise, a
bug in this function would not be caught.

BUG=

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

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

port 634d1d86 (r30874).

original commit message:

    Now both Execution::Call and Execution::New can deal with any
    kind of target and will raise a proper exception if the target is not
    callable (which is not yet spec compliant for New, as we would
    have to check IsConstructor instead, which we don't have yet).

    Now we no longer need to do any of these weird call/construct
    delegate gymnastics in C++, and we finally have a single true
    bottleneck for Call/Construct abstract operations in the code
    base, with only a few special handlings left in the compilers to
    optimize the JSFunction case.

BUG=

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

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

port 10c5f2e8

original commit message:

    Slow path for relational comparison of boolean primitive values
    now goes through the runtime, which made the slow path even
    slower than it already was. So in order to repair the regression,
    we just track boolean feedback for comparisons and use that
    to generate decent code in Crankshaft (not the best possible
    code, but good enough for Crankshaft; TurboFan will be able
    to do better on that).

BUG=

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

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

There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4413, v8:4430
LOG=n

Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
Cr-Commit-Position: refs/heads/master@{#30900}

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

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

Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )

Reason for revert:
Failed on Fuzzer and MIPS bot.

Original issue's description:
> [es6] Introduce spec compliant IsConstructor.
>
> There was already a bit on the Map named "function with prototype",
> which basically meant that the Map was a map for a JSFunction that could
> be used as a constructor. Now this CL generalizes that bit to
> IsConstructor, which says that whatever (Heap)Object you are looking at
> can be used as a constructor (i.e. the bit is also set for bound
> functions that can be used as constructors and proxies that have a
> [[Construct]] internal method).
>
> This way we have a single chokepoint for IsConstructor checking, which
> allows us to get rid of the various ways in which we tried to guess
> whether something could be used as a constructor or not.
>
> Drive-by-fix: Renamed IsConstructor on FunctionKind to
> IsClassConstructor to resolve the weird name clash, and the
> IsClassConstructor name also matches the spec.
>
> R=jarin@chromium.org, rossberg@chromium.org
> BUG=v8:4430
> LOG=n
>
> Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
> Cr-Commit-Position: refs/heads/master@{#30900}

TBR=jarin@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4430

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

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

There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

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

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

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

port 1dfac69f (r30857).

original commit message:

    Introduce new builtins Construct and ConstructFunction (in line
    with the Call and CallFunction builtins that we already have) as
    proper bottleneck for Construct and [[Construct]] on JSFunctions.
    Use these builtins to support passing NewTarget from C++ to
    JavaScript land.

    Long-term we want the CallConstructStub to be used for
    gathering feedback on entry to construction chain (i.e. the
    initial new Foo), and use the Construct builtins to do the
    actual work inside the construction chain (i.e. calling into
    super and stuff).

BUG=

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

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

port c610a222 (r30849).

original commit message:

BUG=

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

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

port e56f265f (r30852).

original commit message:

    Previously we only collected the known map for equality comparisons. But
    if we also collect it for relational comparisons, we can inline a fast
    path of ToPrimitive on the objects, which is especially interesting
    since both sides have the same map.

    For now we only inline a very limited subset of ToPrimitive in
    Crankshaft, which is when the receiver map (and its prototype chain)
    doesn't have @@toPrimitive, and both valueOf and toString are the
    default versions on the %ObjectPrototype%. In this case the relational
    comparison would reduce to a string comparison of "[object CLASS]" with
    itself and so we can reduce that to a boolean constant plus map checks
    on both left and right hand side, plus code dependencies on the
    prototype chain. This repairs the regression on box2d.

BUG=

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

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

Rolling v8/tools/clang to 1cde9025c16dfc3e23be2db010b24f657c255b4c

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

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

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

Introduce a new macro TO_STRING that maps to %_ToString and use that
instead of calling into any of the ToString/NonStringToString JavaScript
builtins. Also remove the TO_STRING_INLINE macro, which is basically
obsolete with %_ToString. We still have a few uses of ToString left (via
the utils export mechanism), where we need to investigate whether we
will tank badly if we replace them with TO_STRING as well.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=yangguo@chromium.org
BUG=v8:4307
LOG=n

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

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

Remove sumOfAbsoluteDifferences functions.

BUG=v8:4124
LOG=Y

R=bbudge@chromium.org, littledan@chromium.org

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

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

R=mstarzinger@chromium.org
BUG=

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

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

R=mstarzinger@chromium.org
BUG=

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

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

We not keep track of the histogram as we process values and do not wait until
printing the histogram. Furthermore processing the histogram is not O(n) for n
values.

BUG=

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

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

For string wrappers (JSValue instances with [[StringData]] internal
fields), we can shortcirciut the ToPrimitive if

  (a) the {input} map matches the initial map of the String function,
  (b) the {input} [[Prototype]] is the unmodified %StringPrototype% (i.e.
      no one monkey-patched toString, @@toPrimitive or valueOf), and
  (c) the %ObjectPrototype% (i.e. the [[Prototype]] of the
      %StringPrototype%) is also unmodified, that is no one sneaked a
      @@toPrimitive into the %ObjectPrototype%.

If all these assumptions hold, we can just take the [[StringData]] value
and return it.

This just repairs a regression introduced by removing the
weird (and broken) intrinsic %_IsStringWrapperSafeForDefaultValue, which
was intendend to something similar to this, although less efficient and
wrong in the presence of @@toPrimitive. Long-term we might want to move
into the direction of having a ToPrimitiveStub that can do common cases
while staying in JavaScript land (i.e. not going to C++).

R=jarin@chromium.org
BUG=chromium:532524
LOG=n

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

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

BUG=chromium:527994
LOG=n

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

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

Revert of [heap] Add more tasks for parallel compaction (patchset #11 id:200001 of https://codereview.chromium.org/1354383002/ )

Reason for revert:
[Sheriff] May have caused this new flake:
http://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/5412

Original issue's description:
> [heap] Add more tasks for parallel compaction
>
> - We now compute the number of parallel compaction tasks, depending on the
>   evacuation candidate list, the number of cores, and some hard limit.
> - Free memory is moved over to compaction tasks (up to some limit)
> - Moving over memory is done by dividing the free list of a given space up among
>   other free lists. Since this is potentially slow we limit the maximum amount
>   of moved memory.
>
> BUG=chromium:524425
> LOG=N
>
> Committed: https://crrev.com/0e842418835eea85886a06cf37052895bc8a17db
> Cr-Commit-Position: refs/heads/master@{#30886}

TBR=hpayer@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

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

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

Whenever a generalization is computed, the inputs must be checked for being cleared, and if they are, the generalization must be Type::Any.

Hopefully this fixes Chromium issue 527994 as well.

BUG=v8:4325,chromium:527994
LOG=n

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

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

- We now compute the number of parallel compaction tasks, depending on the
  evacuation candidate list, the number of cores, and some hard limit.
- Free memory is moved over to compaction tasks (up to some limit)
- Moving over memory is done by dividing the free list of a given space up among
  other free lists. Since this is potentially slow we limit the maximum amount
  of moved memory.

BUG=chromium:524425
LOG=N

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

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

NOTRY=true

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

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

R=bmeurer@chromium.org
BUG=

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

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