MIPS: Fixing MathPowHalf on ARM.

MIPS: Fixing MathPowHalf on ARM.

Port r10166 (b57f3f1a), r10167 (202eada9) and r10170 (5c5c96da).

BUG=
TEST=

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

[kalmard, 2011-12-06 16:15:05]

Building and testing v8 on mips also requires the following patches to be
landed:

http://codereview.chromium.org/8789012/
http://codereview.chromium.org/8821024/

[Yang, 2011-12-06 16:21:53]

This seems to be implemented more complicatedly than necessary. Please clarify.

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

http://codereview.chromium.org/8822014/diff/1/src/mips/lithium-codegen-mips.c...
src/mips/lithium-codegen-mips.cc:3000: 
From what I can see, you don't need to reserve an additional temp register (and
change register allocation in lithium-mips.cc) if you can already take advantage
of a double_scratch0().
Or is this double_scratch0() somehow related to kDoubleRegZero?

[kalmard, 2011-12-08 13:19:26]

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

http://codereview.chromium.org/8822014/diff/1/src/mips/lithium-codegen-mips.c...
src/mips/lithium-codegen-mips.cc:3000: 
On 2011/12/06 16:21:53, Yang wrote:
> From what I can see, you don't need to reserve an additional temp register
(and
> change register allocation in lithium-mips.cc) if you can already take
advantage
> of a double_scratch0().
> Or is this double_scratch0() somehow related to kDoubleRegZero?
I generally try to stick close to the ARM version because in my experience it
makes long-term maintenance easier. However if this has a performance impact or
you feel that the code is better the other way, I will obviously change it.
The change is not related to kDoubleRegZero.