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

Peter Wang novalazy at gmail.com
Fri Sep 5 10:36:34 AEST 2008

On 2008-08-25, Peter Wang <novalazy at gmail.com> wrote:
> On 2008-08-21, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > 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:
> > > 
> > > 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.

I discovered a problem with this approach.  The sharing analysis tracks
variables of d.u. types, but not variables holding typeinfos, closures,
etc.  For stack allocation, we need that. e.g. if we construct a closure
which is returned as part of an output variable, we need to know that so
we don't construct the closure on the stack.  It doesn't look easy to
extend the sharing analysis to non-du types.


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