Port inlined in-object property stores to ARM.

Port inlined in-object property stores to ARM.

Committed: http://code.google.com/p/v8/source/detail?r=5116

[Rodolph Perfetta, 2010-07-21 14:51:15]

http://codereview.chromium.org/2878043/diff/1/2
File src/arm/assembler-arm.cc (right):

http://codereview.chromium.org/2878043/diff/1/2#newcode448
src/arm/assembler-arm.cc:448: bool Assembler::IsStrRegisterImmediate(Instr
instr) {
Should the name indicate this only returns true for word store? (not byte or
halfword)

http://codereview.chromium.org/2878043/diff/1/4
File src/arm/codegen-arm.cc (right):

http://codereview.chromium.org/2878043/diff/1/4#newcode6361
src/arm/codegen-arm.cc:6361: __ mov(scratch0, Operand(Factory::null_value()));
On ARM it should probably be LoadRoot(scratch0, Heap::kNullValueRootIndex);

[Mads Ager (chromium), 2010-07-22 07:29:54]

http://codereview.chromium.org/2878043/diff/1/2
File src/arm/assembler-arm.cc (right):

http://codereview.chromium.org/2878043/diff/1/2#newcode448
src/arm/assembler-arm.cc:448: bool Assembler::IsStrRegisterImmediate(Instr
instr) {
On 2010/07/21 14:51:15, Rodolph Perfetta wrote:
> Should the name indicate this only returns true for word store? (not byte or
> halfword)

We could do that. I chose this name because it matches the assembler name for
the 'str' instruction. We have 'strb' and 'strh' for byte and halfword and could
add IsStrb and IsStrh methods as well if needed.

http://codereview.chromium.org/2878043/diff/1/4
File src/arm/codegen-arm.cc (right):

http://codereview.chromium.org/2878043/diff/1/4#newcode6361
src/arm/codegen-arm.cc:6361: __ mov(scratch0, Operand(Factory::null_value()));
On 2010/07/21 14:51:15, Rodolph Perfetta wrote:
> On ARM it should probably be LoadRoot(scratch0, Heap::kNullValueRootIndex);

Normally, yes. In this specific case I actually want a null_value instance in
the constant pool so I can patch it to the address of a map at runtime.

[William Hesse, 2010-07-22 08:11:23]

LGTM.

http://codereview.chromium.org/2878043/diff/1/4
File src/arm/codegen-arm.cc (right):

http://codereview.chromium.org/2878043/diff/1/4#newcode6246
src/arm/codegen-arm.cc:6246: // deferred code.
It looked like some support for register allocation was being added to ARM.  If
there ever are registers that need to be saved and restored when going to
deferred code, they will be restored when leaving the block, taking more than
one instruction.  Is there a comment or assert that should be added here, or is
this not a likely possibility.

[Mads Ager (chromium), 2010-07-22 08:28:53]

http://codereview.chromium.org/2878043/diff/1/4
File src/arm/codegen-arm.cc (right):

http://codereview.chromium.org/2878043/diff/1/4#newcode6246
src/arm/codegen-arm.cc:6246: // deferred code.
On 2010/07/22 08:11:23, William Hesse wrote:
> It looked like some support for register allocation was being added to ARM. 
If
> there ever are registers that need to be saved and restored when going to
> deferred code, they will be restored when leaving the block, taking more than
> one instruction.  Is there a comment or assert that should be added here, or
is
> this not a likely possibility.

That is a good question. This follows the pattern of the other inlining. The
patching code actually searches for the next branch instruction after the nop
(but if there are any we should block the constant pool for more than one
instruction I guess). In any case, there are a lot of ASSERTS that will trigger
if this goes wrong - we would find code that was not generated for an inline
store and the patching code would trigger ASSERTS.

I'll commit since this is nothing new and we should look into it.