[cmucl-imp] Fwd: Re: Fwd: Re: Frame size for local calls

[Raymond Toy]

Oops.  The previously attached message didn't make it.

Ray


-------- Original Message --------
Subject: 	Re: [cmucl-imp] Fwd: Re: Frame size for local calls
Date: 	Sun, 09 Jan 2011 09:46:23 -0500
From: 	Rob MacLachlan <ram at ri.cmu.edu>
To: 	Raymond Toy <toy.raymond at gmail.com>



It doesn't seem that my attached message made it through to the list
when you forwarded it.  Here it is inline.

  Rob

__________________________________
On 1/4/2011 9:09 AM, Helmut Eller wrote:
> The comment for the ALLOCATE-FRAME vop reads:
>
>    This is emitted directly before either a known-call-local, call-local,
>    or a multiple-call-local.  All it does is allocate stack space for the
>    callee (who has the same size stack as us).
>
> Does that mean that all local calls in a component use the same frame
> size?  Isn't that wasteful?

Yes, it does mean that.   And it does waste some space, but not time,
since it takes the same amount of time to allocate any amount of
(uninitialized) storage.  Unless you have a huge non-tail recursion,
stack usage is likely to be in the 10's of kbytes range, which was not a
big concern for me, even on a machine with 4 meg of memory.   You could
avoid this by generalizing the register allocator to know about frames,
or by doing local call in some other way.  Also, the register allocator
deliberately wastes stack space by allocating stack storage in larger
chunks, under the theory that this will make it more likely that the
source and destination of a move can be packed in the same location,
eliminating a memory-to-memory move.

I think that what has proven to be the biggest adverse consequence of
this stack wastage is that it makes dead pointers appear to still be in
use because they were referenced by some stack slot that was allocated,
but is never used by that function.    Of course, this could happen even
if all of the stack slots were potentially used somewhere inside the
function, since they still might not happen to be live at the time of
the call.

  Rob