in a spilled scope or not. Also get rid of some spilled scopes
that we don't need any more. The generators for the %_ functions,
CodeGenerator::Generate*, are now not spilled by default. Some
of them (IsObject and related) have been converted to register
allocated operation.
Review URL: http://codereview.chromium.org/2368001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4749 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
NumberToUint32 that I was trying to use maps -0 to +0 (as desired) but
also maps +/-Infinity to +0, which made +/-Infinity a valid string
index. I fixed it by introducing a new runtime function with the right
semantics.
TEST=LayoutTests/fast/js/char-at.html,mjsunit/string-charat.js
Review URL: http://codereview.chromium.org/2223003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These string methods can be composed from two basic blocks: charCodeAt
and fromCharCode, both of which have fast cases for certain types of
inputs. In this patch these two blocks are refactored to allow
generating the fast cases without having to jump around the slow
cases. In the slow cases since they can now be invoked both from
inline runtime functions and from IC stubs we either have to
save/restore state of the current frame or enter/leave a new internal
frame. This is handled by new RuntimeCallHelper interface. Its
implementation for virtual frame is based on FrameRegisterState class
extracted from DeferredCode class.
Review URL: http://codereview.chromium.org/2087009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4733 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The macro assembler now checks for ARMv7 support and generates instructions for Ldrd/Strd accordingly. INstructions ldrd/strd in the assembler requires ARMv7 support enabled. This removes the a check for CAN_USE_ARMV7_INSTRUCTIONS making the ARMv7 support in the simulator fully controled by the --enable-armv7 flag.
Review URL: http://codereview.chromium.org/2226003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4726 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The full compiler is now complete on ARM as well. The syntax checker is still used to determine whether to use it for top level code or not during normal execution. When debugging is enabled all code will be compiled with the full compiler.
This change removes the temporary flag --force-full-compiler and now the flag --always-full-compiler enables the full compiler for all code on all platforms.
This also fixes building on Intel platform without debugger support (ENABLE_DEBUGGER_SUPPORT not defined) and adds full check for the full compiler for lazily compiled code.
Review URL: http://codereview.chromium.org/2163006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4716 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- New сardmarking write barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
- Changes to enable oldspaces iteration without maps decoding:
-- layout change for FixedArrays: length is stored as a smis (initial patch by
Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on
arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not
computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special
way.
Review URL: http://codereview.chromium.org/2144006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-- layout change for FixedArrays: length is stored as a smis (initial patch by Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special way.
- Cardmarking write barrier. New barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
Review URL: http://codereview.chromium.org/2101002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4685 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The calling convention for keyed store IC on ARM is changed to receive the arguments value, key and receiver in registers r0, r1 and r2 instead of on the stack. When calling keyed store IC with a virtual frame the arguments are passed through the virtual frame and consumed by the call.
Changed the register usage in the IC code to postpone spilling the registers holding value, key and receiver to the stack until making a call into the runtime system.
Runs all the tests with:
--special-command="@ --nofull-compiler"
--special-command="@ --always-full-compiler"
--special-command="@ --noenable-vfp3"
Review URL: http://codereview.chromium.org/2116003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Chromium build.
v8.gyp no longer sets any V8_TARGET_ARCH_* macro on the Mac. Instead, the
proper V8_TARGET_ARCH_* macro will be set by src/globals.h in the same way as
the V8_HOST_ARCH_* macro when it detects that no target macro is currently
defined. The Mac build will attempt to compile all ia32 and x86_64 .cc files.
#ifdef guards in each of these target-specific source files prevent their
compilation when the associated target is not selected. For completeness,
these #ifdef guards are also provided for the arm and mips .cc files.
BUG=706
TEST=x86_64 Mac GYP/Xcode-based Chromium build (still depends on other changes)
Review URL: http://codereview.chromium.org/2133003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of having a list of virtual frame pointers in the jump
target we have one virtual frame, which is the frame that
all have to merge to to branch to that frame. The virtual
frame in the JumpTarget is inside the JumpTarget, rather than
being an allocated object that is pointed to. Unfortunately
this means that the JumpTarget class has to be able to see
the size of a VirtualFrame object to compile, which in turn
lead to a major reorganization of related .h files. The
actual change of functionality in this change is intended
to be minimal (we now assert that the virtual frames match
when using JumpTarget instead of just assuming that they do).
Review URL: http://codereview.chromium.org/1961004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4631 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The change r4608 accidently disabled the inlined keyed load as the key/receiver registers was mixed up. Also make sure that the registers for the keyed load IC is not clobbered before bailout to deferred code. This adds one instriction to the inlined code path.
Review URL: http://codereview.chromium.org/2018005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4629 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The calling convention for keyed load IC's on ARM now passes the key and receiver in registers r0 and r1.
The code path in the ARM full compiler for handling keyed property load now has the same structure as for ia32 where the keyed load IC is also called with key end receiver in registers.
This change have been tested with an exhaustive combinations of the flags
--special-command="@ --nofull-compiler"
--special-command="@ --always-full-compiler"
--special-command="@ --noenable-vfp3"
to the test runner.
Review URL: http://codereview.chromium.org/2024002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4608 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The calling convention for keyed load IC is changed to have the key passed both in a register (r0) and on the stack.
Next steps will be first to remove the key from the stack and then pass the receiver in a register (r1).
Review URL: http://codereview.chromium.org/1937003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is mainly a port of r3899. It also adds handling of initilization blocks in ARM which had no special handling before.
The "calling conventions" used for
EmitNamedLoad
EmitNamedStore
EmitKeyedLoad
EmitKeyedStore
are somewhat mixed, but will become more aligned as the use of register allication and passing of argument in registers to IC's is extended.
Review URL: http://codereview.chromium.org/1846002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4574 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
Generate inlined named property load for in-object properties. This uses the same mechanism as on the Intel platforms with the map check and load instruction of the inlined code being patched by the inline cache code. The map check is patched through the normal constant pool patching and the load instruction is patched in place.
Review URL: http://codereview.chromium.org/1715003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the CEntryStub keep track of the actual skew from the correct alignment to ensure proper alignment before calling the runtime. Add checks to test the expected skew when running on hardware.
Use the PrepareCallCFunction/CallCFunction in a few other places.
Add check to the ARM simulator for correct alignment.
Add option --sim-stack-alignment to set the stack alignment in the simulator. Currntly only values 4 and 8 makes sense. 8 is the default to make snapshots generated with the simulator work on hardware requiring 8 byte stack alignment.
Review URL: http://codereview.chromium.org/1530043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4425 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
stack for now. Next step is probably fixing the binary
op stubs so they can take swapped registers and fixing
the deferred code so it doesn't insist that all registers
except the two operands are flushed. Generates slightly
worse code sometimes because the peephole push-pop
elimination gets confused when we don't use the same
register all the time (the old code used r0 always).
Review URL: http://codereview.chromium.org/1604002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4368 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This re-applies r4220 and r4233, which was reverted in r4254 due to a bug. This bug has now been fixed, with the only change being line 2884 changed from
__ SmiTag(left_side->reg());
to
__ SmiTag(operand->reg());
Added a regression test.
BUG=http://crbug.com/39160
TEST=test/mjsunit/regress/regress-crbug-39160.js
Review URL: http://codereview.chromium.org/1251009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4261 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Inline floating point compare instead of calling the stub when the following conditions are met:
* Code is in a loop
* Compare is not a for loop condition
* Compare is not an equal comparison
This inlined code handles heap number to heap number and heap number to smi compare. It can also handle smi to smi compare, but whenever there is a chance of comparing two smis the smi compare is inlined before the inlined floating point compare. Support for non SSE2 hardware is included.
A new set of variants of the compare stub without the floating point comparison code is called if the inline comapre fails due to the operands not beeing heap numbers or smis.
The virtual frame has been extended with a branch taking two live results to be carried through to the destination. This makes this change much simpler as the inlined code have two live results in registers and a number of bailouts.
CompareStub::GetName needs to be updated as well. I will do that as a separate change.
Also inlined equality check if both operands can't be NaN. This can only provide positive equals if it is the same object.
Review URL: http://codereview.chromium.org/1117011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The inline runtime functions are now included in the fuzzing of the natives. The chack for the expected number of arguments passed have been moved to the parser which will generate a syntax error if a runtime function (either C++ or inline) is called with a different number of arguments than expected.
Review URL: http://codereview.chromium.org/573056
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Introducing a virtual-frame-inl.h file containing some platform-independent
virtual frame function which are small enough to be inlined.
Removed unnecessary #include of virtual-frame.h from register-allocator-inl.h
and added the necessary explicit includes in a number of files.
Review URL: http://codereview.chromium.org/660104
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3962 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
