[m-dev.] for design review: accurate GC for MLDS back-end

[Fergus Henderson]

On 25-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> I've been thinking about doing accurate GC for the MLDS back-end,
> and I've sketched out some design documentation.
...
> %	static void
> %	foo_traverse_frame(void *this_frame) {
> %		struct foo_frame *frame = (struct foo_frame *)this_frame;
> %		MR_GC_TRAVERSE(<type_info for type of arg1>, &frame->arg1);
> %		MR_GC_TRAVERSE(<type_info for type of local1>, &frame->local1);
> %		...
> %	}
...
> One difficulty with this design that I've spotted so far is that computing
> type_infos may be difficult in an MLDS->MLDS transformation.

OK, I have some ideas on how to do this now.

The subroutine for generating code to construct type_infos is in
polymorphism__make_type_info_vars.  It takes as input a list of types,
and some other information including a proc_info, and generate a list of
HLDS goals.  This is invoked by polymorphism.m and also by other HLDS->HLDS
passes (e.g. table_gen.m) that insert calls to polymorphic builtin procedures.

We can't invoke this in an MLDS->MLDS transformation, because we don't
have the HLDS around at that point.

We do have all the information needed to invoke this routine at HLDS->MLDS
code generation time.  So in ml_code_gen.m we can invoke
polymorphism__make_type_info_vars to generate these HLDS goals
to generate the type_infos, and then we can immediately convert
them to MLDS statements.

However, at that point, we don't know where these statements are going
to go.  So my idea is to attach the MLDS statement for tracing each
variable to the MLDS variable definition (modifying the MLDS as shown in
the diff below).  ml_code_gen.m will generate variable definitions with
the calls to MR_GC_TRAVERSE() attached, and then ml_elim_nested.m can
move these calls out into the appropriate foo_traverse_frame() function.

Does that sound reasonable?

Index: mlds.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/mlds.m,v
retrieving revision 1.77
diff -u -d -u -u -4 -r1.77 mlds.m
--- mlds.m	8 Nov 2001 11:47:59 -0000	1.77
+++ mlds.m	7 Dec 2001 07:11:19 -0000
@@ -448,9 +448,13 @@
 :- type mlds__entity_defn
 		% constants or variables
 	--->	mlds__data(
 			mlds__type,
-			mlds__initializer
+			mlds__initializer,
+				% If accurate GC is enabled, we associate
+				% with each variable the code needed to
+				% trace that variable when doing GC.
+			maybe(mlds__gc_trace_code)
 		)
 		% functions
 	;	mlds__function(
 			maybe(pred_proc_id),	% identifies the original
@@ -462,8 +466,10 @@
 		% packages, classes, interfaces, structs, enums
 	;	mlds__class(
 			mlds__class_defn
 		).
+
+:- type mlds__gc_trace_code == mlds__statement.
 
 	% It is possible for the function to be defined externally
 	% (i.e. the original Mercury procedure was declared `:- external').
 	% (If you want to generate an abstract body consider adding another

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------