MIPS: Use allocatable registers for Interpreter.

MIPS: Use allocatable registers for Interpreter.

Registers s0, s1 were not in the pool of allocatable registers, so the
assembler failed a DCHECK.  Move them to allocatable, as on the other
arches.

TEST=unittests/InterpreterAssemblerTest.LoadRegisterFixed, others.
BUG=

[paul.l..., 2015-07-27 02:40:51]

paul.lind@imgtec.com changed reviewers:
+ akos.palfi@imgtec.com, balazs.kilvady@imgtec.com, rmcilroy@chromium.org

[paul.l..., 2015-07-27 02:40:52]

PTAL. 

FWIW, I've opened an issue to increase the number of allocatable regs on MIPS
arch-variants that will support it (mips64 and mips32r6).

Interestingly, we are limited by the number of FPU regs (16 total, 14
allocatable on mips32r2) due to this, in lithium-allocator.cc:

STATIC_ASSERT(DoubleRegister::kMaxNumAllocatableRegisters >=
              Register::kMaxNumAllocatableRegisters);

[rmcilroy, 2015-07-27 07:45:23]

On 2015/07/27 02:40:52, paul.l... wrote:
> PTAL. 
> 
> FWIW, I've opened an issue to increase the number of allocatable regs on MIPS
> arch-variants that will support it (mips64 and mips32r6).
> 
> Interestingly, we are limited by the number of FPU regs (16 total, 14
> allocatable on mips32r2) due to this, in lithium-allocator.cc:
> 
> STATIC_ASSERT(DoubleRegister::kMaxNumAllocatableRegisters >=
>               Register::kMaxNumAllocatableRegisters);

Are t1 and t2 callee saved for JS calls? If so, lgtm. Thanks!

[paul.l..., 2015-07-27 15:56:13]

On 2015/07/27 07:45:23, rmcilroy (OOO until 10th Aug) wrote:
> Are t1 and t2 callee saved for JS calls? If so, lgtm. Thanks!

No, these new regs are not callee-saved, and your original s0,s1 are, but are
not in our 'allocatable' list. Let me see what I can do here. Since you're OOO,
I expect we have a little time, I might land this to fix the bots, with an issue
to resolve it.

[rmcilroy, 2015-07-28 07:45:15]

On 2015/07/27 15:56:13, paul.l... wrote:
> On 2015/07/27 07:45:23, rmcilroy (OOO until 10th Aug) wrote:
> > Are t1 and t2 callee saved for JS calls? If so, lgtm. Thanks!
> 
> No, these new regs are not callee-saved, and your original s0,s1 are, but are
> not in our 'allocatable' list. Let me see what I can do here. Since you're
OOO,
> I expect we have a little time, I might land this to fix the bots, with an
issue
> to resolve it.

I'm OOO but still working from Munich until Friday :). Landing this to unblock
you for now should be fine until you find a better solution - we won't be making
any calls from the interpreter for a while, so it won't matter whether they are
callee-saved or not until then.

[paul.l..., 2015-07-29 04:34:46]

On 2015/07/28 07:45:15, rmcilroy (OOO until 10th Aug) wrote:
> I'm OOO but still working from Munich until Friday :). Landing this to unblock
> you for now should be fine until you find a better solution - we won't be
making
> any calls from the interpreter for a while, so it won't matter whether they
are
> callee-saved or not until then.

I presume you're using callee-saved to preserve them thru runtime calls from
interpreter.

Arm CEntryStub now now uses r4, r5, which will conflict with your use of r5 for
InterpreterBytecodeOffsetReg() in https://codereview.chromium.org/1245133002/

It looks to me like the use of Call(r5) no longer needs to be callee-saved, and
any reg would work. There are a few stale comments there about callee saved,
which were true before the old retry loop was removed in
https://codereview.chromium.org/240053010. Only argc needs to use callee-saved
now.

I'm removing related cruft in the mips CEntryStub to free up s0-s2 for
interpreter use.

[rmcilroy, 2015-07-29 07:58:56]

On 2015/07/29 04:34:46, paul.l... wrote:
> On 2015/07/28 07:45:15, rmcilroy (OOO until 10th Aug) wrote:
> > I'm OOO but still working from Munich until Friday :). Landing this to
unblock
> > you for now should be fine until you find a better solution - we won't be
> making
> > any calls from the interpreter for a while, so it won't matter whether they
> are
> > callee-saved or not until then.
> 
> I presume you're using callee-saved to preserve them thru runtime calls from
> interpreter.
> 
> Arm CEntryStub now now uses r4, r5, which will conflict with your use of r5
for
> InterpreterBytecodeOffsetReg() in https://codereview.chromium.org/1245133002/
> 
> It looks to me like the use of Call(r5) no longer needs to be callee-saved,
and
> any reg would work. There are a few stale comments there about callee saved,
> which were true before the old retry loop was removed in
> https://codereview.chromium.org/240053010. Only argc needs to use callee-saved
> now.
> 
> I'm removing related cruft in the mips CEntryStub to free up s0-s2 for
> interpreter use.

Actually after talking this over with folks in Munich, I realize that we are
always going to need to spill these registers when making any calls to stubs
even if they are callee-saved. As such, leaving these as s0-s2 should be fine.
I've done this in https://codereview.chromium.org/1254293006/, so this CL
shouldn't be needed any more (and no need to clean up your CEntryStub just for
this).

[paul.l..., 2015-11-04 18:18:08]

Description was changed from

==========
MIPS: Use allocatable registers for Interpreter.

Registers s0, s1 were not in the pool of allocatable registers, so the
assembler failed a DCHECK.  Move them to allocatable, as on the other
arches.

TEST=unittests/InterpreterAssemblerTest.LoadRegisterFixed, others.
BUG=
==========

to

==========
MIPS: Use allocatable registers for Interpreter.

Registers s0, s1 were not in the pool of allocatable registers, so the
assembler failed a DCHECK.  Move them to allocatable, as on the other
arches.

TEST=unittests/InterpreterAssemblerTest.LoadRegisterFixed, others.
BUG=
==========