The first jump to a specific label was marked as jump to absolute
position -4. This value was stored in the assembly as a branch to a
offset (-4 - (instruction offset + 8)). The offset is only 24 bit
long on ARM. Thus instruction offsets higher than 2^23 - 12 would overflow
the offset.
Fix by denoting the first jump to a label by storing the jump
instruction location as the target. This will result in offset of -8,
which of course always fits in the branch instruction.
BUG=2736
TEST=cctest/test-assembler-arm/17
R=bmeurer@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17116006
Patch from Kimmo Kinnunen <kkinnunen@nvidia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Refactoring:
* consistent use of SmiTag/Untag
* added a few Smi macros and helpers
Improvements
* small optimisations (e.g. merging untag and cmp #0)
* added fixed point to double conversion instructions for simpler conversions
More on the last point: a Smi can be seen as a fixed point number with the
a one bit fractional part. Fixed to double instructions allow us to convert
a Smi to a double without untagging.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/15085026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14724 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch defines new makefile command line paramaters to better control the
ARM specific options. The new paramters are
* armfpu = vfp, vfpv3-d16, vfpv3, neon.
* armfloatabi = softfp, hard
* armneon = on
* armthumb = on, off
* armtest = on
One existing paratemer has been modified:
* armv7 = true, false
A number of parameters have been deprecated (but are still working):
* hardfp = on, off
* vfp2 = off
* vfp3 = off
the armtest paratmer when set to "on" will lock the options used during compile
time at runtime. This allows for example to easily test the ARMv6 build on an
ARMv7 platform without having to worry about features detected at runtime. When
not specified the compiler default will be used meaning it is not necessary
anymore to specify hardfp=on when natively building on an hardfp platform.
The shell help now prints the target options and features detected.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/14263018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14288 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
First of all, it has nothing to do with Isolates, it is related to the assembler
at hand. Furthermore, the saving/restoring is platform-independent. Cleaned up
some platform-specific stuff on the way.
Note that there are some things which still need some cleanup, like e.g. using
EnumSet instead of uint64_t, making Probe() more uniform across platforms etc.,
but the CL is already big enough.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12391055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes us generate faster code for DoStoreKeyedFixedDoubleArray,
by using a branch rather than a conditional Vmov instruction.
Conditional VFP instructions are not a great idea in general, and it was
especially bad in this case because Vmov expands to a bunch of instructions.
For this reason, the patch also removes the 'cond' parameter from Vmov.
Thanks to Rodolph for pointing me to this!
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12316096
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13722 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The assembler has 8 different vmov variants. The one for vmov.32 and for moving
an immediate into a double reg only differs in the type of the second
paremeter: vmov.32 takes an int, the other takes a double.
The situation is dangerous because C++ will happily implicitly convert between
int and double.
This patch changes the signature of the vmov.32 assembler function so that it
cannot be confused with the other vmovs.
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12255031
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The previously-used instruction isn't guaranteed to always be undefined,
and the encoding used was conditional (failing the condition on an
undefined instruction is itself undefined and not guaranteed to
fault!). I would have like to use a more clever encoding (see bug 2963),
but we need the extra bits to encode the size of the constant pool.
BUG=security
R=ulan@chromium.org
Review URL: https://chromiumcodereview.appspot.com/11242002
Patch from JF Bastien <jfb@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12791 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
regardless of the detected CPU. This is a requirement for the
debugger and the deoptimizer, which both expect that code from
the snapshot (compiled without VFP and ARM7) should have the
same layout as code compiled later.
This is another change to make snapshots more robust with
arbitrary code.
Review URL: https://chromiumcodereview.appspot.com/10824235
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12287 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mksnapshot or a VM that is booted from a snapshot. --debug-code
can still have an effect on stub and optimized code and it still
works on the full code generator when running without snapshots.
The deoptimizer generates full-code-generator code and relies on it having
the same layout as last time. This means that the code the full code
generator makes for the snapshot should be the same as the code it makes
later. This change makes the full code generator create more consistent
code between mksnapshot time and run time.
This is a bug fix and a step towards making the snapshot code more robust.
Review URL: https://chromiumcodereview.appspot.com/10834085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12239 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
C++'s 'great' idea of implicitly converting an enum to an integral value hit us
again, this time resulting in silly (but currently non-harmful) entries in the
relocation table. Encapsulated the AST ID recording a bit, which helped a lot to
find the culprit.
Review URL: http://codereview.chromium.org/7400016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8671 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
