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

Peter Wang novalazy at gmail.com
Thu Aug 21 19:08:44 AEST 2008

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.

> 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.


mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au

More information about the developers mailing list