is both on top of the stack and also in r0. This makes
sense because the receiver is usually in r0 anyway. We may
remove it from the stack later. Also removes some spilled
scopes from the code generator allowing it to keep expression
temporaries in registers more.
Review URL: http://codereview.chromium.org/1751019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4518 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This uses the same infrastructure as is used by the inlining of named property load. The code patching if the inlined code is simpler as the key is provided in a register os the only patching required is the map check directing the inlined code to the deferred code block or not.
Review URL: http://codereview.chromium.org/1735007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The generation of the deferred code for named property load where the load was inlined did a constant pool blocking for the whole deferred code. Having large numbers of this type of deferred code generated one ofter the other effectively blocked the constant pool for all the deferred code causing
Removed the BeforeGenerate/AfterGenerate for the deferred code and made macro assembler StartBlockConstPool/EndBlockConstPool non-public. Re-introduced BlockConstPoolFor instead to use with BlockConstPoolScope to block some more instructions cross function calls.
Also handle the use of native code counters for inlined named property load.
Review URL: http://codereview.chromium.org/1787005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4507 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The V8 GYP file now uses its own target architecture. It default to the standard target_arch, but can be set to a separate value. E.g. using
export GYP_DEFINES="target_arch=ia32 v8_target_arch=arm"
makes it possible to have the V8 ARM simulator be used in a IA32 build.
Added some checking of supported host/target architecture combinations.
Review URL: http://codereview.chromium.org/1790001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A reference to the caches array was embedded directly into the builtin
code and this allowed sharing objects between contexts.
Unfortunately, clearing the cache on GC won't prevent sharing so we
either have to have per-context builtin code or load the cache
indirectly from the current context. This change implements the second
approach. The first approach may be interesting to consider in the
future for some perfomance critical functions, and the current
approach can still be improved by putting the caches directly into the
global context (or even global objects).
Review URL: http://codereview.chromium.org/1731002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4486 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
On a pair of smis HEAP_NUMBERS stub is significantly slower than GENERIC. This slows
down some tests dramatically (crypto-aes from SunSpider).
With this change HEAP_NUMBERS stub switches to GENERIC stub the first time it sees 2 smis
as its operands.
Review URL: http://codereview.chromium.org/1687005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4483 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instaed of having a nop after all non-inlined calls to load IC use a different nop (mov r1, r1 instead of mov r0, r0) to detect an inlined load IC.
Added more infrastructure to the deferred code handling to make it possbile to block constant pool emitting in a deferred code block, including the branch instruction ending the deferred code block.
Addressed a couple of comments to http://codereview.chromium.org/1715003, including adding an assert to make sure that the patching of an ldr instruction is always possible.
Review URL: http://codereview.chromium.org/1758003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4480 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- RelinkPageListInChunkOrder might relink unused pages into the middle of a sequence of used pages. Filler objects should be placed at the beginning of such unused pages otherwise generic iterators (e.g. HeapObjectIterator) would not handle them correctly.
- ObjectAreaEnd() should not be used as an allocation limit for pages from FixedSpace. Pages in such spaces do not use top page_extra_ bytes of object area.
TBR=ager@chromium.org
Review URL: http://codereview.chromium.org/1700005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
