ARM: Implement DoDivI in the lithium code generator.

ARM: Implement DoDivI in the lithium code generator.

This change provides fast code for a few special cases and calls the GenericBinaryOpStub for the rest. 

It also changes the register allocation in the generation of lithium instructions to use fixed registers that are compatible with the generic stub. This allocation can be change once we use a more flexible implementation.

Finally, this change provides infrastructure to save double registers at safepoints, which is need to call the stub in deferred code.

BUG=
TEST=

[Søren Thygesen Gjesse, 2011-01-13 08:28:38]

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-arm.cc
File src/arm/lithium-arm.cc (right):

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-arm.cc#newcode1242
src/arm/lithium-arm.cc:1242: // TODO(karlklose) The fixed register allocation
Please open a bug to track this, and change to TODO(number).

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

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:884: const int32_t kTwoHighestBits = 3<<30;
In other parts of the code we write this as 0xc0000000 without using a constant.

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:885: __ and_(scratch, left,
Operand(kTwoHighestBits));
You can use SetCC on the and instruction to set the Z flag if scratch is zero.
Then you only need one cmp for the 0xc0000000 case. You could also take a look
at Smi::IsValid in objects-inl.h. There 0x4000000 is added and the result is
checked against 0x80000000 (unsigned). Maybe add a SmiTag  instruction variant
to the macro assembler which jumps to a label if the value does not fit in a
smi.

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:888: __ b(eq, &deoptimize);
There is a SmiTag instruction in the macro assembler.

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:897: GenericBinaryOpStub stub(Token::DIV,
OVERWRITE_LEFT, left, right);
The LDivI instruction is not marked as call which means that it will not spill
registers to the stack. Therefore it is not safe to call a stub. It needs to be
called from deferred code and marked with "RecordSafepointWithRegisters". As the
GenericBinaryOpStub might touch floating point registers as well we need to have
a safepoint with both registers and doubles.

[Karl Klose, 2011-01-13 13:52:31]

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-arm.cc
File src/arm/lithium-arm.cc (right):

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-arm.cc#newcode1242
src/arm/lithium-arm.cc:1242: // TODO(karlklose) The fixed register allocation
On 2011/01/13 08:28:38, Søren Gjesse wrote:
> Please open a bug to track this, and change to TODO(number).

Done.

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

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:884: const int32_t kTwoHighestBits = 3<<30;
I have created a TrySmiTag instruction in the macro assembler to abstract over
this code.

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:885: __ and_(scratch, left,
Operand(kTwoHighestBits));
s.a.

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:888: __ b(eq, &deoptimize);
s.a.

http://codereview.chromium.org/6164005/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:897: GenericBinaryOpStub stub(Token::DIV,
OVERWRITE_LEFT, left, right);
On 2011/01/13 08:28:38, Søren Gjesse wrote:
> The LDivI instruction is not marked as call which means that it will not spill
> registers to the stack. Therefore it is not safe to call a stub. It needs to
be
> called from deferred code and marked with "RecordSafepointWithRegisters". As
the
> GenericBinaryOpStub might touch floating point registers as well we need to
have
> a safepoint with both registers and doubles.

Done.

[Søren Thygesen Gjesse, 2011-01-13 15:38:29]

LGTM

http://codereview.chromium.org/6164005/diff/11001/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (left):

http://codereview.chromium.org/6164005/diff/11001/src/arm/lithium-codegen-arm...
src/arm/lithium-codegen-arm.cc:2513: __ ldr(result, FieldMemOperand(result,
JSGlobalPropertyCell::kValueOffset));
Accidental edit?

http://codereview.chromium.org/6164005/diff/11001/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):

http://codereview.chromium.org/6164005/diff/11001/src/arm/lithium-codegen-arm...
src/arm/lithium-codegen-arm.cc:943: __ str(r0, MemOperand(sp,
DwVfpRegister::kNumAllocatableRegisters *
I think this deserves at least a comment. On
http://codereview.chromium.org/6248004 from I made the following comment on
almost the same construct

n IA32 we have EspIndexForPushAll, and I think we need something like that here,
maybe a macro assembler instruction like StoreToSafePointRegister to work in
correspondance with PushSafepointRegisters/PopSafepointRegisters.