The construction of arrays when using the the Array function either as a constructor or a normal function is now handled fully in generated code in most cases. Only when Array is called with one argument which is either negative or abowe JSObject::kInitialMaxFastElementArray (which is currently 1000) or if the allocated object cannot fit in the room left in new space is the runtime system entered.
Two new native code built-in functions are added one for normal invocation and one for the construct call. The existing C++ builtin is renamed, but kept. When the normal invocation cannot be handled in generated code the C++ builtin is called. When the construct invocation cannot be handled in native code the generic construct stub is called (which will end up in the C++ builtin through a construct trampoline).
One thing that might be changed is preserving esi (constructor function) during the handling of a construct call. We know precisily what function we where calling anyway and can just reload it. This could remove the parameter construct_call to ArrayNativeCode and remove the handling of this from that function.
The X64 and ARM implementations are not part of this changelist.
Review URL: http://codereview.chromium.org/193125
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The main piece of this change was to add support for break on return for ARM. On ARM the normal js function return consist of the following code sequence.
mov sp, fp
ldmia sp!, {fp, lr}
add sp, sp, #4
bx lr
to a call to the debug break return entry code using the following code sequence
mov lr, pc
ldr pc, [pc, #-4]
<debug break return entry code entry point address>
bktp 0
The values of Assembler::kPatchReturnSequenceLength and Assembler::kPatchReturnSequenceLength are somewhat misleading, but they fit the current use in the debugger. Also Assembler::kPatchReturnSequenceLength is used in the IC code as well (for something which is not related to return sequences at all). I will change that in a separate changelist.
For the debugger to work also added recording of the return sequence in the relocation info and handling of source position recording when a function ends with a return statement.
Used the constant kInstrSize instead of sizeof(Instr).
Passes all debugger tests on both simulator and hardware (only release mode tested on hardware).
Review URL: http://codereview.chromium.org/199075
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Objects which require an additional fixed array to be allocated now have this allocated in generated code as well. Added allocation flags to the macro assembler new space allocation routines.
Changed the ia32 and x64 macro assemblers to take allocation flags to the allocation routines instead of boolean flag.
Review URL: http://codereview.chromium.org/201015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change moves the allocation of new objects into generated code. The allocation will bail out into the runtime system if the number of properties to allocate for the object exceeds the number of in-object properties.
Review URL: http://codereview.chromium.org/175045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2797 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a
specialized constructor stub is now generated. This generated code allocates the
object and fills in the initial properties directly. If this fails for some
reason code continues in the generic constructor stub which in turn might pass
control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change.
For x64 and ARM the generic construct stub is used.
This is change is identical to http://codereview.chromium.org/174392 (committed in r2753 and reverted in r2754) except that a few parts have already been committed from http://codereview.chromium.org/173469 (committed in r2762).
Review URL: http://codereview.chromium.org/173470
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a specialized constructor stub is now generated. This generated code allocates the object and fills in the initial properties directly. If this fails for some reason code continues in the generic constructor stub which in turn might pass control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change. For x64 and ARM the generic construct stub is used.
Review URL: http://codereview.chromium.org/174392
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
they do nothing. The frame is currently always spilled, so they were
not doing anything useful.
The call sites have been left alone to mark where spills will
eventually be needed if we begin doing register allocation on ARM.
Review URL: http://codereview.chromium.org/164136
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2644 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
fast-mode compiler.
1. We avoid generating a useless temporary for assignments with
nontrivial right-hand sides. Instead of translating id = expr into:
...
tmp = <last expr instruction>
id = tmp
we generate directly
...
id = <last expr instruction>
by passing a data destination ('hint') down the AST. The semantics is
to use the destination as a result location if a temp is needed. It
may be ignored. NULL indicates I don't care and you should generate a
temp.
2. We correctly handle assignments as subexpressions. When building
the CFG for an expression we accumulate the assigned variables and we
emit a move to a fresh temporary if a value in a variable is in
jeopardy of being overwritten.
Review URL: http://codereview.chromium.org/165056
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2643 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
