Port inline version of Math.sqrt and Math.pow from ia32 to x64.

Port inline version of Math.sqrt and Math.pow from ia32 to x64.

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

[William Hesse, 2010-04-28 13:46:01]

LGTM if cvtsi2sd is removed.

http://codereview.chromium.org/1774010/diff/1/3
File src/x64/assembler-x64.cc (right):

http://codereview.chromium.org/1774010/diff/1/3#newcode2489
src/x64/assembler-x64.cc:2489: void Assembler::cvtsi2sd(XMMRegister dst,
Register src) {
This is the same as cvtlsi2sd() 22 lines above this.  The l or q prefix says
whether we are using a 32- or 64- bit general purpose register as the source.

http://codereview.chromium.org/1774010/diff/1/5
File src/x64/codegen-x64.cc (right):

http://codereview.chromium.org/1774010/diff/1/5#newcode4042
src/x64/codegen-x64.cc:4042: 
I wonder if there is any case where we can get a smi and HeapNumber version of
the same integer, that are obviously equal, but so that Pow(x, y_smi) is
different than Pow(x, y_float).  Is that a problem?

http://codereview.chromium.org/1774010/diff/1/5#newcode4046
src/x64/codegen-x64.cc:4046: // on both arguments and that the arguments are not
the same
The assumption is really that the two arguments are not copies of each other, so
that an x = y before the use of %Math.pow(x, y) would also be a problem.  But we
don't actually use the assumption!  The spill of exponent.reg() means that base
will be loaded in a different register, even if it is a copy.  There is no
assumption.  Even the remaining two copies, on the frame, may be copies, because
they are only used to call runtime.

http://codereview.chromium.org/1774010/diff/1/5#newcode4073
src/x64/codegen-x64.cc:4073: __ cvtsi2sd(xmm3, answer.reg());
These should all be cvtlsi2sd, I think.

http://codereview.chromium.org/1774010/diff/1/5#newcode4256
src/x64/codegen-x64.cc:4256: __ AllocateHeapNumber(result.reg(), scratch.reg(),
&runtime);
If you allocate the heap number before doing the calculation, you can go to
runtime if allocation fails, to definitely allocate one, and then do the
calculation knowing that you have a heap number to store the result in.

[Mads Ager (chromium), 2010-04-28 14:42:53]

http://codereview.chromium.org/1774010/diff/1/3
File src/x64/assembler-x64.cc (right):

http://codereview.chromium.org/1774010/diff/1/3#newcode2489
src/x64/assembler-x64.cc:2489: void Assembler::cvtsi2sd(XMMRegister dst,
Register src) {
On 2010/04/28 13:46:02, William Hesse wrote:
> This is the same as cvtlsi2sd() 22 lines above this.  The l or q prefix says
> whether we are using a 32- or 64- bit general purpose register as the source.

Whoops, yes of course. Thanks!

http://codereview.chromium.org/1774010/diff/1/5
File src/x64/codegen-x64.cc (right):

http://codereview.chromium.org/1774010/diff/1/5#newcode4042
src/x64/codegen-x64.cc:4042: 
On 2010/04/28 13:46:02, William Hesse wrote:
> I wonder if there is any case where we can get a smi and HeapNumber version of
> the same integer, that are obviously equal, but so that Pow(x, y_smi) is
> different than Pow(x, y_float).  Is that a problem?

Apparently it hasn't been so far. It is a bit weird though.

http://codereview.chromium.org/1774010/diff/1/5#newcode4046
src/x64/codegen-x64.cc:4046: // on both arguments and that the arguments are not
the same
On 2010/04/28 13:46:02, William Hesse wrote:
> The assumption is really that the two arguments are not copies of each other,
so
> that an x = y before the use of %Math.pow(x, y) would also be a problem.  But
we
> don't actually use the assumption!  The spill of exponent.reg() means that
base
> will be loaded in a different register, even if it is a copy.  There is no
> assumption.  Even the remaining two copies, on the frame, may be copies,
because
> they are only used to call runtime.

You are right, I just copied the comments from the ia32 version. I'll remove
that comment from both before submitting. Thanks.

http://codereview.chromium.org/1774010/diff/1/5#newcode4073
src/x64/codegen-x64.cc:4073: __ cvtsi2sd(xmm3, answer.reg());
On 2010/04/28 13:46:02, William Hesse wrote:
> These should all be cvtlsi2sd, I think.

Done.

http://codereview.chromium.org/1774010/diff/1/5#newcode4256
src/x64/codegen-x64.cc:4256: __ AllocateHeapNumber(result.reg(), scratch.reg(),
&runtime);
On 2010/04/28 13:46:02, William Hesse wrote:
> If you allocate the heap number before doing the calculation, you can go to
> runtime if allocation fails, to definitely allocate one, and then do the
> calculation knowing that you have a heap number to store the result in.

Good point, we can do that on both ia32 and x64 as a separate change and see if
it matters.