X64: Remove more fpu code. Unroll more local initialization loops.

X64: Remove more fpu code. Unroll more local initialization loops.

[Lasse Reichstein, 2010-06-24 07:38:10]

Only FPU code left is transcendental functions and fmod.

[William Hesse, 2010-06-24 07:56:25]

LGTM.

http://codereview.chromium.org/2815028/diff/1/6
File src/x64/virtual-frame-x64.cc (right):

http://codereview.chromium.org/2815028/diff/1/6#newcode119
src/x64/virtual-frame-x64.cc:119: // For less locals the unrolled loop is more
compact.
For fewer locals

http://codereview.chromium.org/2815028/diff/1/6#newcode124
src/x64/virtual-frame-x64.cc:124: ASSERT(tmp.is_valid());
If this does not work, is it worth copying rax to kScratchRegister, then using
rax for the pushes?

http://codereview.chromium.org/2815028/diff/1/6#newcode141
src/x64/virtual-frame-x64.cc:141: __ movb(cnt.reg(), Immediate(count));
Doesn't movb leave the upper bits unchanged?  We need to clear them.  Oh, I see
you are using decb.  Put a comment saying this.  Doesn't this introduce partial
register dependencies?  I'm not sure this is worth it.

[Lasse Reichstein, 2010-06-24 09:02:24]

http://codereview.chromium.org/2815028/diff/1/6
File src/x64/virtual-frame-x64.cc (right):

http://codereview.chromium.org/2815028/diff/1/6#newcode119
src/x64/virtual-frame-x64.cc:119: // For less locals the unrolled loop is more
compact.
Fixed.

http://codereview.chromium.org/2815028/diff/1/6#newcode124
src/x64/virtual-frame-x64.cc:124: ASSERT(tmp.is_valid());
Probably not. This code happens on entry to the function, so it's incredibly
likely that one of the first four registers are free, and if it happens most of
the time, it's fine (I'm guessing there is really a 100% chance of getting rax,
but I'm still satisfied if it's only 90%). Also, it only cost one extra byte per
push if we fail to get one of the low registers, and if there are many pushes,
we go to the loop anyway, so the damage is minimal.
This is really a micro-optimization for code size in the common case more than
anything else.

http://codereview.chromium.org/2815028/diff/1/6#newcode141
src/x64/virtual-frame-x64.cc:141: __ movb(cnt.reg(), Immediate(count));
There should be no partial register read stalls on intel processors, since we
only read the part we just wrote (there is no need to merge partial registers).
On AMD processors there should be no problem either, since it always merges
immediately, and there is no dependencies that we have to wait for.