emitted as part of the safepoint tables.
Always emit the constant pool as part of generating deferred code
(whether or not there actually is any deferred code) and ASSERT that
there is no pending relocation info while using db and dd to write
tables.
Review URL: http://codereview.chromium.org/6360003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6347 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix the ARM simulator, the ARM disassembler and extend the stop feature.
The stop feature in the simulator now support enabling, disabling and
counting.
BUG=None
TEST=None
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5723 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Upgraded the CodeGenerator::ToBoolean() function in the ARM backend to use complete JIT code generation and not make runtime calls to ToBool (when VFP is enabled).
This change also includes the vcmp VFP instruction that supports a constant 0.0 as the second operand.
Patch by Subrato K De <subratokde@codeaurora.org>
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5267 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When calculating Math.pow where the exponent is a smi use a simple loop to calculate the result.
Added support for the vmov instruction moving from one doubleword extension register to another.
Added some Math.pow tests which partially covers what is in the Sputnik tests.
Review URL: http://codereview.chromium.org/2804033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4990 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A potential issue with this change is creating lots of maps when
objects flip between fast/slow elements modes. We could add special
transitions to avoid this. Yet testing this on our benchmarks, gmail,
and wave seems to indicate that this is not a real problem.
Review URL: http://codereview.chromium.org/2870018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4941 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Zhang Kun. For now we only emit movw and movt in places where no
relocation is needed. Small performance boost (around 0.5%).
Also adds support for turning ALU operations (eor etc.) with
large immediates into mvn or movw followed by a register-based
ALU operation.
Review URL: http://codereview.chromium.org/2821014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4913 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added support for more precise break points when debugging and stepping. To achieve that additional nop instructions are inserted where breaking would otherwise be impossible. The number of nop instructions inserted are sufficient to make place for patching with a call to a debug break code stub. On Intel that is 5 nop's for 32-bit and 13 for 64-bit. Om ARM 3 nop instructions (12 bytes) are required.
In order to avoid inserting nop's in to many places a simple ast checker have been added to check whether there are breakable code in a statement or expression. If it is possible to break in an expression no additional break enabeling code is inserted.
Added break locations to the true and false part of a conditional expression.
Added stepping tests to cover more constructs.
These changes are only in the full compiler.
Changed the default value for the option --debugger in teh d8 shell from true to false. The reason for this is that with --debugger turned on the full compiler will be used for all code in when running d8, which can be unexpeceted.
Review URL: http://codereview.chromium.org/2693002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4820 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When ldrd is not available two ldr instructions are generated. This fixes these in the case where the register used in the memory operand is the same as the first register in the register pair receiving the values.
All tests now run on ARM with the flag --special-command="@ --noenable-vfp3". Running without VFP3 support in the simulator causes more ldrd instructions to be used, and the default build configuration does not utilize ldrd, but generated tow ldr instructions.
Review URL: http://codereview.chromium.org/2078013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4667 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
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
