This also changes load computation to use HeapTypes rather than Maps.
TODO: move conversion between maps and heaptypes earlier in the process, already in the oracle.

BUG=
R=dcarney@chromium.org

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

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

R=ulan@chromium.org

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

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

version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).

The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.

Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function.  This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).

We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once.  The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address.  Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones.  Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).

Concerns:

- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)

- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.

- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer.  However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.

Thanks for any feedback.

R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=18918

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

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

BUG=v8:3125
R=bmeurer@chromium.org
TBR=verwaest@chromium.org
LOG=n

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

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

Port r18902 (ba394fbc)

Original commit message:
This has the additional benefit that it is now possible to
inline the RegExpResult construction code into Hydrogen
builtins.

BUG=
R=plind44@gmail.com

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

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

R=jkummerow@chromium.org
TBR=jkummerow@chromium.org

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

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

Port r18905 (88f14cd3)

BUG=
R=plind44@gmail.com

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

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

BUG=
TBR=hpayer@chromium.org

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

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

BUG=
R=mvstanton@chromium.org

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

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

Make sure builtin code objects get their builtin tags
first. Otherwise a particular JSFunction object could set
its custom name to a generic builtin.

LOG=N
R=ulan@chromium.org, yurys@chromium.org

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

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

Now including release mode.

BUG=v8:3125
LOG=n
TBR=verwaest@chromium.org

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

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

R=jarin@chromium.org

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

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

BUG=
R=jkummerow@chromium.org

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

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

These tests register extensions on the isolate and the configuration of the extensions runs out of scope. If run in parallel, other tests access the isolate's state and read the registered extensions.

BUG=
R=dcarney@chromium.org

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

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

BUG=v8:3125
LOG=n
TBR=verwaest@chromium.org

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

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

mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).

The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.

Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function.  This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).

We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once.  The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address.  Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones.  Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).

Concerns:

- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)

- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)

- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.

- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer.  However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.

Thanks for any feedback.

R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=

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

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

- Let Mozilla tests with timeouts always run in no-variants mode. Otherwise the stress-run causes a 16 minutes timeout in debug mode and 32 minutes on arm debug.
- Four test cases with exponentially long running regular expressions are skipped entirely.

BUG=
R=jkummerow@chromium.org

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

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

Make a template version of SubStringKey, which allows internalization of substrings of sequential and external strings.

R=dcarney@chromium.org, svenpanne@chromium.org

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

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

Follow-up to r18298.

R=verwaest@chromium.org

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

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

R=svenpanne@chromium.org

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

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

LOG=N
R=ulan@chromium.org, yurys@chromium.org

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

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

R=svenpanne@chromium.org

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

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

R=svenpanne@chromium.org

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

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

R=mstarzinger@chromium.org

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

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

This has the additional benefit that it is now possible to
inline the RegExpResult construction code into Hydrogen
builtins.

R=mvstanton@chromium.org

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

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

R=mvstanton@chromium.org

BUG=

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

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

R=svenpanne@chromium.org

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

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

R=svenpanne@chromium.org

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

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

R=svenpanne@chromium.org

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

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

R=jkummerow@chromium.org
TBR=jkummerow@chromium.org

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

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

R=svenpanne@chromium.org

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

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

BUG=v8:3069
LOG=Y
R=rossberg@chromium.org

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

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

R=svenpanne@chromium.org

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

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

This commit fixes the global object loading to load the result into the "result" register instead of the "receiver" register.

TEST=mjsunit/compiler/regress-arguments
BUG=
R=plind44@gmail.com, verwaest@chromium.org

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

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

This commit fixes the global object loading to load the result into the "result" register instead of the "receiver" register.

BUG=
R=verwaest@chromium.org

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

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

Use this for detecting MSVCRT library features instead of
V8_CC_MSVC.

One use case for this is when compiling with Clang together with the
MSVC library. In that case, V8_CC_MSVC will be false, but V8_LIBC_MSVCRT
will be true.

BUG=82385
LOG=n
R=bmeurer@chromium.org

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

Patch from Hans Wennborg <hans@chromium.org>.

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

R=titzer@chromium.org

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

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

R=titzer@chromium.org

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

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

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

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

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

BUG=
R=mvstanton@chromium.org

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

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