Refactor loading a pointer and loading an integer64 into a register instructions for X64

Refactor loading a pointer and loading an integer64 into a register instructions for X64

R=danno@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=17540

[haitao.feng, 2013-10-24 07:28:11]

This is a follow-up CL of https://codereview.chromium.org/26410004/.

Next I plan to refactor a pure 64-bit movq (no condition) into the assembler,
and move the movq(Register, void*, RelocInfo::Mode) and movq(Register, int64_t)
into macro assembler.

[haitao.feng, 2013-10-24 07:32:48]

Some comments inlined. I could continue refactoring in this CL if you prefer.

https://codereview.chromium.org/39543003/diff/1/src/x64/assembler-x64.cc
File src/x64/assembler-x64.cc (right):

https://codereview.chromium.org/39543003/diff/1/src/x64/assembler-x64.cc#newc...
src/x64/assembler-x64.cc:1533: movq(dst, Smi::cast(*value), RelocInfo::NONE64);
In the macro assembler, we have Move(Register, Smi*), I will try to use that
when move this instruction into macro assembler.

https://codereview.chromium.org/39543003/diff/1/src/x64/lithium-codegen-x64.cc
File src/x64/lithium-codegen-x64.cc (right):

https://codereview.chromium.org/39543003/diff/1/src/x64/lithium-codegen-x64.c...
src/x64/lithium-codegen-x64.cc:160: __ movq(kScratchRegister,
reinterpret_cast<Address>(kSlotsZapValue),
It might make sense to define kSlotsZapValue as Address in v8globals.h, but that
requires to change ARM and MIPS assembler a little.

[danno, 2013-10-24 11:13:17]

https://codereview.chromium.org/39543003/diff/1/src/x64/lithium-codegen-x64.cc
File src/x64/lithium-codegen-x64.cc (right):

https://codereview.chromium.org/39543003/diff/1/src/x64/lithium-codegen-x64.c...
src/x64/lithium-codegen-x64.cc:160: __ movq(kScratchRegister,
reinterpret_cast<Address>(kSlotsZapValue),
On 2013/10/24 07:32:48, haitao.feng wrote:
> It might make sense to define kSlotsZapValue as Address in v8globals.h, but
that
> requires to change ARM and MIPS assembler a little.

Why can't this just stay int64_t and remove the  ode? The slot zap value isn't
really an Address.

[haitao.feng, 2013-10-24 11:52:33]

> Why can't this just stay int64_t and remove the  ode? The slot zap value isn't
> really an Address.
For X32, this value is int32_t. Actually the size of this value is equal to a
pointer size, like a SMI.

[haitao.feng, 2013-10-24 13:17:03]

Danno, you are right. Sorry for the confusion.

https://codereview.chromium.org/39543003/diff/1/src/x64/lithium-codegen-x64.cc
File src/x64/lithium-codegen-x64.cc (right):

https://codereview.chromium.org/39543003/diff/1/src/x64/lithium-codegen-x64.c...
src/x64/lithium-codegen-x64.cc:160: __ movq(kScratchRegister,
reinterpret_cast<Address>(kSlotsZapValue),
On 2013/10/24 11:13:17, danno wrote:
> On 2013/10/24 07:32:48, haitao.feng wrote:
> > It might make sense to define kSlotsZapValue as Address in v8globals.h, but
> that
> > requires to change ARM and MIPS assembler a little.
> 
> Why can't this just stay int64_t and remove the  ode? The slot zap value isn't
> really an Address.

Done.

[haitao.feng, 2013-10-25 06:19:10]

https://codereview.chromium.org/39543003/diff/170001/src/x64/assembler-x64.cc
File src/x64/assembler-x64.cc (right):

https://codereview.chromium.org/39543003/diff/170001/src/x64/assembler-x64.cc...
src/x64/assembler-x64.cc:1470: void Assembler::movq(Register dst, int64_t value)
{
Use MacroAssembler::Set instruction if the value could be coerced to uint32_t or
int32_t.

https://codereview.chromium.org/39543003/diff/170001/src/x64/assembler-x64.cc...
src/x64/assembler-x64.cc:1518: ASSERT(!RelocInfo::IsNone(mode));
Currently SMI cases are all handled before calling this movq.

[danno, 2013-11-04 16:44:16]

lgtm

[haitao.feng, 2013-11-05 01:46:37]

Thanks, I will commit it when the tree is open again.

[haitao.feng, 2013-11-07 08:14:52]

Committed patchset #3 manually as r17540 (presubmit successful).