Port handling of heap numbers in deferred code for binary ops from...

Port handling of heap numbers in deferred code for binary ops from
ia32 to x64.


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

[Lasse Reichstein, 2010-04-29 12:36:40]

LGTM

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

http://codereview.chromium.org/1692015/diff/1/3#newcode5915
src/x64/codegen-x64.cc:5915: __ SmiToInteger32(left_, left_);
If you have a spare register here, you could convert left_ into an integer in
that and not have to convert it back afterwards.
This is X64 - it should be possible to allocate a register - or can't we because
this is deferred code?

http://codereview.chromium.org/1692015/diff/1/3#newcode5921
src/x64/codegen-x64.cc:5921: __ AllocateHeapNumber(dst_, left_,
&after_alloc_failure);
I'll bet I can make a version of AllocateHeapNumber/AllocateInNewSpace that
doesn't use any scratch registers (except for kScratchRegister ofcourse).
That would save you from push/popping here - if you can't get a scratch register
somehow.

[Mads Ager (chromium), 2010-05-03 08:47:08]

I have committed this change in its current state. Once you have the
AllocateHeapNumber method that does not require a scratch register we should get
rid of the push/pop of left_.

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

http://codereview.chromium.org/1692015/diff/1/3#newcode5915
src/x64/codegen-x64.cc:5915: __ SmiToInteger32(left_, left_);
On 2010/04/29 12:36:40, Lasse Reichstein wrote:
> If you have a spare register here, you could convert left_ into an integer in
> that and not have to convert it back afterwards.
> This is X64 - it should be possible to allocate a register - or can't we
because
> this is deferred code?

I can convert the smi into an integer in kScratchRegister and load it from
there. I don't think it will matter for performance since in that case we will
just transform two shifts into a move and a shift.

I have left it as is.