Experimental: this is a substantial change to allow the virtual frame...

Experimental: this is a substantial change to allow the virtual frame
to flow correctly to deferred code.

The same mechanism is used for all labeled blocks (potential merge
points), not just deferred ones: all live mergable values are held on
the frame.  At a jump or branch, local results are allowed to be
passed as arguments to the target block, with the semantics of being
pushed on the frame before performing the jump or branch.  At a bind,
the arguments to the block are named, with the semantics of performing
the bind and then popping the arguments from the frame.

"Returns" from deferred code are handled the same way (the return
value is an argument to the block labeled with the deferred code exit
label).

There is obviously still some things to clean up here.


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

[Kevin Millikin (Chromium), 2008-12-19 14:24:12]

Blocks now take arguments.  For jumps, branches, and bind with an active frame,
each argument will be one of the arguments to one of the phi functions at the
merge.  For binding a label, the arguments also serve as the lhs of the phi
assignments in the labeled block.

The biggest change is that the deferred code now explicitly binds its entry
label and jumps to its exit rather than having the infrastructure do it.  The
"advantage" is that we have an opportunity to be explicit about the calling
convention for the deferred code and use symbolic names.

[William Hesse, 2008-12-22 13:55:21]

Only one potential error found by me.

http://codereview.chromium.org/15079/diff/401/601
File src/register-allocator-ia32.cc (right):

http://codereview.chromium.org/15079/diff/401/601#newcode95
Line 95: }
I think we are missing the case where this.reg() is target,
but target occurs multiple times in the frame.  We need to spill target in that
case, I think.

http://codereview.chromium.org/15079/diff/401/601#newcode109
Line 109: Use(edi);
Aren't we going to need to unuse edi before the ValidRegisters check at
JumpTarget works?

http://codereview.chromium.org/15079/diff/401/607
File src/register-allocator-ia32.h (right):

http://codereview.chromium.org/15079/diff/401/607#newcode100
Line 100: // it.
How can we move a result into a register that isn't spilled? Are you referring
to the case that the result is already in a register?  Then it isn't being
moved.  Otherwise, aren't we messing up the value already in the register?

http://codereview.chromium.org/15079/diff/401/607#newcode199
Line 199: // necessary, or else fail and regutrn an invalid result.
and return an invalid result.

[Kevin Millikin (Chromium), 2008-12-22 14:39:59]

http://codereview.chromium.org/15079/diff/401/601
File src/register-allocator-ia32.cc (right):

http://codereview.chromium.org/15079/diff/401/601#newcode95
Line 95: }
On 2008/12/22 13:55:21, William Hesse wrote:
> I think we are missing the case where this.reg() is target,
> but target occurs multiple times in the frame.  We need to spill target in
that
> case, I think.

Yes, according to the comment in the header we do.  Fixed.

We still need to handle the case that the target register is multiply referenced
outside the frame (or otherwise unallocatable, which amounts to the same thing).

http://codereview.chromium.org/15079/diff/401/601#newcode109
Line 109: Use(edi);
On 2008/12/22 13:55:21, William Hesse wrote:
> Aren't we going to need to unuse edi before the ValidRegisters check at
> JumpTarget works?
> 

We can't jump before Enter is called on the frame.  That seems reasonable.

http://codereview.chromium.org/15079/diff/401/607
File src/register-allocator-ia32.h (right):

http://codereview.chromium.org/15079/diff/401/607#newcode100
Line 100: // it.
On 2008/12/22 13:55:21, William Hesse wrote:
> How can we move a result into a register that isn't spilled? Are you referring
> to the case that the result is already in a register?  Then it isn't being
> moved.  Otherwise, aren't we messing up the value already in the register?

Yes, the comment refers to the case where the result is in a register.  In that
case, the current register is as arbitrary as any other.