It is available platforms that have SSE 4.1 and allows us to handle
negative numbers without deoptimization. Before we would deoptimize
on negative inputs to Math.floor. x64 already uses this instruction.
* Change Math.floor unit test to make sure every test case gets
optimized by changing the source code for each test case.
* Fix HIR debug printing for some instructions.
Review URL: http://codereview.chromium.org/7628017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is IA32 only for now.
Added a random value to each assembler instance (JIT cookie) to be used for constant splitting. Added safe versions of setting a register with an immediate value and for pushing an immediate value. Used these functions where user controlled immediate values could be emitted in the code stream. I also used it for immediates which are an argument number even though the number of formal arguments is currently limited to 16k.
I found no compares directly with user controlled constants.
I am not sure whether the test is that useful, but it might catch some changes missing constant splitting.
Review URL: http://codereview.chromium.org//7005031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7868 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Make esi available to the register allocator rather than dedicating it
permanently to the context.
The context is still passed in register esi to JavaScript and to the runtime
as part of the calling convention. Because some stubs might end up calling
JS or the runtime, it is also conservatively passed to stubs.
Roughly half the calls have been modified to use the context as an input
value in fixed register esi. The other half are marked as calls or deferred
code so esi is spilled and can be explicitly set.
It is no longer necessary to restore the context to esi after a call that
might change it.
Review URL: http://codereview.chromium.org/6452001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is an improved version of my earlier change r5970. It avoids degrading the
non-optimized code.
Initially we emit a conditional branch that is either always- or never-taken
after a smi-check (depending on whether we test for smi for for non-smi)
Since test-eax always sets the carry-flag to 0 we use jump-if-carry and
jump-if-not-carry.
The first invocation of the stub patches a jc with a jz and
jnc with a jnz-instruction so that the code looks exactly as it was
without patching. The only difference is the test- or nop-instruction
after the IC-call.
Review URL: http://codereview.chromium.org/5763004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6030 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the case of inlined smi code in non-optimzied code we could not
distinguish between the smi-only case and the case that the operation was
never executed.
With this change the first execution of a binary operation always jumps
to the stub which in turn patches the smi-check into the correct
conditional branch, so that we benefit from inlined smi code after the
first invocation.
A nop instruction after the call to the BinaryOpIC indicates that no
smi code was inlined. A "test eax" instruction says that there was smi
code inlined and encodes the delta to the patch site and the condition
code of the branch at the patch site to restore the original jump.
Review URL: http://codereview.chromium.org/5714001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5970 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The number of inobject properties used to be derived from the number
of this property assignments in the constructor (and increased by 2 to
allow for properties added later). This very often leads to wasted inobject
slots.
This patch reclaims some of the unused inobject space by the following method:
- for each constructor function the first several objects are allocated using the initial
("generous) instance size estimation (this is called 'tracking phase').
- during the tracking phase map transitions are tracked and actual property counts are collected.
- at the end of the tracking phase instance sizes in the maps are decreased if necessary
(starting with the function's initial map and traversing the transition tree).
- all further allocation use more realistic instance size estimation.
Shrinking generously allocated objects without costly heap traversal is made possible
by initializing their inobject properties with one_pointer_filler_map (instead of undefined).
The initial slack for the generous allocation is increased from 2 to 6 which really helps some tests.
Review URL: http://codereview.chromium.org/3329019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change introduces near labels in the assembler, allowing us to
uptimize forward jumps (conditional and unconditional) if we can
guarantee that the jump is witin range -128 to +127.
I changed a large fractions of the existing Labels to NearLabels, and
left out cases where it was not immediately clear if it could be used
or not (not immediately clear means labels covering a large code
block, or used in function calls which we could potentially change to
accept near labels).
Review URL: http://codereview.chromium.org/3388004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5460 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
