[m-dev.] Attn Peter Wang: CTGC idea.

[Paul Bone]

On Thu, Aug 21, 2008 at 07:08:44PM +1000, Peter Wang wrote:
> On 2008-08-21, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > On Thu, Aug 21, 2008 at 05:26:21PM +1000, Peter Wang wrote:
> > > 
> > > Yes, I suppose we could.  So if you construct a cell and it dies by the
> > > end of the procedure, and remains unique, then you don't have to
> > > allocate it on the heap.  We can't use the detstack.  The C stack might
> > > work, but I'm not sure how portable that would be.  On the high-level C
> > > grade we could use a local variable.
> > 
> > ah a local variable should be fine in the hlc backend,  I forgot that
> > alloca is only useful when you don't know the size of the allocation at
> > the time of writing the code.
> > 
> > Why can't we use the detstack?  surely we can use it when executing code
> > with at most one solution? or is this because we can't allocate
> > multiple-word objects on the detstack?
> 
> I think there's an invariant that stack frames don't change size.  I was
> thinking what happens if one branch wants to bind X to a 2-word cell, and
> another branch wants to bind X to a 3-word cell.  But, within reason, we
> could just reserve enough space in the stack frame for the largest cell
> size that a variable will need.

This is where a call to alloca in each branch can allocate as much space
as needed by no more.  However Julien mentioned (IRL) that alloca is not
portable as it's impossible to implement for the program stack on some
architectures.

> > I don't think we can use the C stack at all in low level C grades.
> > Since we jump over the beginning and ends of functions where the C stack
> > is manipulated, the memory would never be collected.
> 
> You're right.
> 
> I think this might work for the analysis.  Assume Nancy's sharing
> analysis has been run, so we know (conservatively) all the variables
> that share with output variables of the procedure.  If a variable being
> constructed doesn't (potentially) share with an output variable, it can
> be stack allocated.
> 

We should analyze how many heap alrogithms we can potentially save, to
provide motivation for this optimisation.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20080821/f2d66fbf/attachment.sig>