Port r17547 (a4b59e4)

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17572 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is controlled by two flags:

--redirect_code_traces
--redirect_code_traces_to=<filename>

When redirection is enabled but --redirect_code_traces_to is not specified traces are written to a file code-<pid>-<isolate>.asm. This mangling scheme matches hydrogen.cfg and allows easy discovery of compilation artifacts in a multi-V8 environment (e.g. when compilation is traced from inside Chromium).

D8 defines --redirect_code_traces_to=code.asm similar to hydrogen.cfg redirection.

BUG=
R=danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17571 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Also introduce a flag for a quick check that concurrency is on.

R=jkummerow@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17570 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jkummerow@chromium.org
BUG=v8:2987
TEST=mjsunit/regress/regress-2987

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17569 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

 - Avoid calls into ToPositiveInteger for valid cases of 'undefined' arguments.
  (Otherwise it calls into runtime).
 - Reduce the checks performed in case offset for TypedArrayFromArrayBuffer
  constructor is called with no offset argument.

R=yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17567 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=rafaelw@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17566 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This instruction is required for copying characters from sequential
strings in the hydrogenized StringAddStub.

BUG=v8:2990
R=svenpanne@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17565 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=danno@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17564 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit r17562 for invalid usage of movw to load string
characters. Will reland with fix.

TBR=svenpanne@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17563 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This instruction is required for copying characters from sequential
strings in the hydrogenized StringAddStub.

BUG=v8:2990
R=svenpanne@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17562 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17560 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mvstanton@chromium.org

Review URL: https://chromiumcodereview.appspot.com/64003004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17559 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This moves building of constant properties and elements arrays for all
materialized literals into the compiler. The parser no longer allocates
while parsing ObjectLiteral and ArrayLiteral expressions.

R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17557 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

To get back the old behavior, use "make randomseed=0 ...".

BUG=v8:1880,v8:2885
R=jkummerow@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ulan@chromium.org

Review URL: https://chromiumcodereview.appspot.com/64023003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17554 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ulan@chromium.org

Review URL: https://chromiumcodereview.appspot.com/61773004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17551 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ulan@chromium.org

Review URL: https://chromiumcodereview.appspot.com/26968004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17550 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17547 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=dcarney@chromium.org
BUG=v8:2984

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17545 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=bmeurer@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17541 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17540 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Tiny superficial cleanup to make the similarities more visible.
Removed a few useless assertions on the way.

R=bmeurer@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17539 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

Patch from Haitao Feng <haitao.feng@intel.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17538 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17537 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port r17521 (c51c75e)

Original commit message:
This improves the generated code for HSeqStringSetChar across
all platforms, taking advantage of constant operands whenever
possible. It also drops the unused DefineSameAsFirst constraint
for the register allocator on x64 and ia32, where it caused
unnecessary spills when the string operand was live across the
HSeqStringSetChar instruction.

A new GVN flag StringChars is introduced to express dependencies
between HSeqStringSetChar, HStringCharCodeAt and the upcoming
HSeqStringGetChar (the GVNFlags type is now 64bit in size).

Also improves the test case.

TEST=mjsunit/string-natives
BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17536 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port r17525 (55b95f3)

Original commit message:
Our generic KeyedStoreIC doesn't handle the case when a callback is
set on array elements in the prototype chain of the object, nor do
we recognize that we need to avoid the monomorphic case if these
callbacks exist.

This CL addresses the issue by looking for dictionary elements in
the prototype chain on IC misses and crankshaft element store
instructions. When found, the generic IC is used. The generic IC is
changed to go to the runtime in this case too.

In general, keyed loads are immune from this problem because they
won't return the hole: discovery of the hole goes to the runtime where
the callback will be found in the prototype chain. Double array loads
in crankshaft can return the hole but only if the prototype chain is
unaltered (we will catch such alterations).

Includes the following patch as well (already reviewed by bmeurer):
Performance regression found in test regress-2185-2.js. The problem was
that the bailout method for TransitionAndStoreStub was not performing
the appropriate transition.

(Review URL for the ElementsTransitionAndStoreIC_Miss change:
https://codereview.chromium.org/26911007)

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17535 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Revert "Landing https://codereview.chromium.org/40133004 for mnita@google.com." due to test failures.

R=ulan@chromium.org

Review URL: https://chromiumcodereview.appspot.com/62563002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17533 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Implements ES6 String.prototype.normalize method.

BUG=v8:2943
TEST=Unit tests for "real life" use cases, edge cases, various types of normalization.
TBR=svenpanne@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17532 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17531 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=verwaest@chromium.org
TBR=verwaest@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17530 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Note that I've left the layering as is to make the diffs clear. Is it worth moving ForceSetObjectProperty to objects.cc? This code is clearly implementing part of the DefineOrRedefine steps from the spec, but it's still odd that it lives in Runtime. Note that handles.cc exposes a ForceSetProperty which just performs a CALL_HEAP_FUNCTION on the Runtime::ForceSetObjectProperty -- which is exposed to the api as v8::Object::ForceSet

BUG=
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17529 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Also, do not allocate sub-closures for every call to typed array constructor.

R=yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17528 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ulan@chromium.org
BUG=309723

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17526 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Our generic KeyedStoreIC doesn't handle the case when a callback is
set on array elements in the prototype chain of the object, nor do
we recognize that we need to avoid the monomorphic case if these
callbacks exist.

This CL addresses the issue by looking for dictionary elements in
the prototype chain on IC misses and crankshaft element store
instructions. When found, the generic IC is used. The generic IC is
changed to go to the runtime in this case too.

In general, keyed loads are immune from this problem because they
won't return the hole: discovery of the hole goes to the runtime where
the callback will be found in the prototype chain. Double array loads
in crankshaft can return the hole but only if the prototype chain is
unaltered (we will catch such alterations).

Includes the following patch as well (already reviewed by bmeurer):
Performance regression found in test regress-2185-2.js. The problem was
that the bailout method for TransitionAndStoreStub was not performing
the appropriate transition.

(Review URL for the ElementsTransitionAndStoreIC_Miss change:
https://codereview.chromium.org/26911007)

R=danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17523 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17522 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This improves the generated code for HSeqStringSetChar across
all platforms, taking advantage of constant operands whenever
possible. It also drops the unused DefineSameAsFirst constraint
for the register allocator on x64 and ia32, where it caused
unnecessary spills when the string operand was live across the
HSeqStringSetChar instruction.

A new GVN flag StringChars is introduced to express dependencies
between HSeqStringSetChar, HStringCharCodeAt and the upcoming
HSeqStringGetChar (the GVNFlags type is now 64bit in size).

Also improves the test case.

TEST=mjsunit/string-natives
R=mstarzinger@chromium.org, yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17521 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Note the spec now reflects the updated naming:

http://wiki.ecmascript.org/doku.php?id=harmony:observe_spec_changes

R=rossberg@chromium.org, rossberg
BUG=v8:2940

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17520 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Apparently, this wasn't the cause for dromaeo regressions.

> BUG=none
> R=jkummerow@chromium.org
>
> Review URL: https://codereview.chromium.org/26457002

R=verwaest@chromium.org, jkummerow@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jkummerow@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/60513010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17516 ce2b1a6d-e550-0410-aec6-3dcde31c8c00