[m-rev.] for review: [CTGC] direct structure reuse analysis (1/2)

[Julien Fischer]

On Wed, 3 May 2006, Nancy wrote:

>
> Hi Julian,
>
> many thanks for your reviewing work! I'm starting to address your
> feedback... here some responses...
>
> >>Index: compiler/hlds_goal.m
> >>===================================================================
> >>RCS file: /home/mercury1/repository/mercury/compiler/hlds_goal.m,v
> >>retrieving revision 1.155
> >>diff -u -d -r1.155 hlds_goal.m
> >>--- compiler/hlds_goal.m	20 Apr 2006 05:36:52 -0000	1.155
> >>+++ compiler/hlds_goal.m	27 Apr 2006 09:29:59 -0000
> >>@@ -769,6 +769,8 @@
> >>                 hlds_goal   % goal to execute if match succeeds.
> >>             ).
> >>
> >>+:- func case_get_goal(case) = hlds_goal.
> >>+
> >
> >
> > Why not just give the fields in the case structure names and use the
> > automatically generated field access function to retrieve the goal.
> >
> > e.g.
> > 	:- type case --->
> > 		case(
> > 			case_functor :: cons_id,
> > 			case_goal    :: hlds_goal
> > 		).
> >
>
> Just to be sure that I'm not missing anything and that I have understood
> the documentation right:
>
> Using these field names, this enables me to use the field access
> functions "case_functor/1" and "case_goal/1". But these functions can
> not be used in higher order calls as is, but must be part of a lambda
> expression?
> That doesn't help much with my code... I'm using case_get_goal only in
> higher order calls, so now I've replaced them all with a copy/paste of
> lambda expressions?

Sorry, I forgot about that :-(

> Where is the gain?

Nowhere as it turns out.

> >>Index: compiler/options.m
> >>===================================================================
> >>RCS file: /home/mercury1/repository/mercury/compiler/options.m,v
> >>retrieving revision 1.511
> >>diff -u -d -r1.511 options.m
> >>--- compiler/options.m	26 Apr 2006 03:05:38 -0000	1.511
> >>+++ compiler/options.m	27 Apr 2006 09:30:36 -0000
> >>@@ -530,6 +530,9 @@
> >>     % Stuff for the CTGC system (structure sharing / structure reuse).
> >>     ;       structure_sharing_analysis
> >>     ;           structure_sharing_widening
> >>+    ;       structure_reuse_analysis
> >>+    ;           structure_reuse_constraint
> >>+    ;           structure_reuse_constraint_arg
> >>
> >>     % Stuff for the new termination analyser.
> >>     ;       termination2
> >>@@ -1149,6 +1152,9 @@
> >>     verbose_check_termination           -   bool(no),
> >>     structure_sharing_analysis          -   bool(no),
> >>     structure_sharing_widening          -   int(0),
> >>+    structure_reuse_analysis            -   bool(no),
> >>+    structure_reuse_constraint        -   string("within_n_cells_difference"),
> >>+    structure_reuse_constraint_arg      -   int(0),
> >>     termination                         -   bool(no),
> >>     termination_single_args             -   int(0),
> >>     termination_norm                    -   string("total"),
> >>@@ -1981,6 +1987,12 @@
> >> % CTGC related options.
> >> long_option("structure-sharing",    structure_sharing_analysis).
> >> long_option("structure-sharing-widening", structure_sharing_widening).
> >>+long_option("structure-reuse",      structure_reuse_analysis).
> >>+long_option("ctgc",                 structure_reuse_analysis).
> >>+long_option("structure-reuse-constraint", structure_reuse_constraint).
> >>+long_option("ctgc-constraint",      structure_reuse_constraint).
> >>+long_option("structure-reuse-constraint-arg", structure_reuse_constraint_arg).
> >>+long_option("ctgc-constraint-arg",  structure_reuse_constraint_arg).
> >
> >
> > You must also update the predicate option_defaults_2 in order to
> > provide default values for the new options.
>
> Isn't that what is given a couple of lines above? Or am I missing
> something?

Ah ... you're right, I misread that bit as continuation of the bit above
it.

...

> >>+% which result in the 'best' form of memory reuse possible for the given goals.
> >>+%
> >>+% Hence, the assignment problem is translated into a mapping problem (inspired
> >>+% from Debray's paper: "On copy avoidance in single assignment languages", and
> >>+% restricted to reuse of dead cells by at most one new cell).
> >>+%
> >>+% When assigning constructions to dead deconstructions, a table is first
> >>+% computed. For each dead cell, a value is computed that reflects the gain
> >>+% a reuse might bring, and the list of constructions involved with reusing it.
> >>+% The cell with highest value is selected first, the according constructions
> >>+% are annotated, and the table is recomputed. This process is repeated until
> >>+% no reusable dead deconstructions are left.
> >>+%
> >>+% The value of a dead cell (a specific deconstruction) is computed taking
> >>+% into account the call graph which can be simplified to take only into account
> >>+% construction-unifications, conjunctions, and disjunctions.
> >
> >
> > Does it also take calls into account?
>
> No. What exactly do you mean?

The reason I asked was I wasn't sure what you meant by call-graph in the
following:

	The value of a dead cell (a specific deconstruction) is computed
	taking into account the call-graph ...

Julien
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------