[m-rev.] for review: compiler support for rbmm

Julien Fischer juliensf at csse.unimelb.edu.au
Wed Jul 25 15:27:31 AEST 2007


On Wed, 25 Jul 2007, Zoltan Somogyi wrote:

> The changes to ite_gen, disj_gen, code_info, llds and llds_out are for review
> by Quan, but I would like someone to review the rest of the diff as well
> (which will require reviewing the change to llds as well).
>
> Zoltan.
>
> ---------------------------------------------------------------------------
>
> Add a first draft of the code generator support for region based memory
> management. It is known to be incomplete; the missing parts are marked by XXXs.
> It may also be buggy; it will be tested after Quan adds the runtime support,
> i.e. the C macros invoked by the new LLDS instructions. However, the changes
> in this diff shouldn't affect non-RBMM operations.
>
> compiler/llds.m:
> 	Add four new LLDS instructions. Three are specific to RBMM operations.
> 	RBMM embeds three new stacks in compiler-reserved temp slots in
> 	procedure's usual Mercury stack frames, and the three new LLDS
> 	instructions respectively
>
> 	(i)   push those stack frames onto their respective stacks,
> 	(ii)  fill parts of those stack frames, and
> 	(iii) use the contents of and/or pop those stack frames.
>
> 	(The pushing and popping affect only the new embedded stacks, not the
> 	usual Mercury stacks.)
>
> 	The fourth instruction is a new variant of the old assign instruction.
> 	It has identical semantics, but restricts optimization. An assign
>
> 	(a) can be deleted if its target lval is not used, and
> 	(b) its target lval can be changed (e.g. to a temp register) as long as
> 	    all the later instructions referring to that lval are changed to
> 	    use the new lval instead.
>
> 	Neither is permitted for the new keep_assign instruction. This is
> 	required because we use it to assign to stack variables (parts of the
> 	embedded stack frames) that aren't explicitly referred to in later LLDS
> 	code, but are nevertheless implicitly referred to by some instructions
> 	(specifically iii above).
>
> 	Extend the type that describe the contents of lvals to allow it
> 	to describe the new kinds of things we can now store in them.
>
> compiler/ite_gen.m:
> 	Surround the code we generate for the condition of if-then-elses
> 	with the code required to ensure that regions that are logically
> 	removed in the condition aren't physically destroyed until we know
> 	that the condition succeeds (since the region may still be needed
> 	in the else branch), and to make sure that if the condition fails,
> 	all the memory allocated since the entry into the condition is
> 	reclaimed instantly.
>
> compiler/disj_gen.m:
> 	Surround the code we generate for disjunctions with the code required
> 	to ensure that regions that are logically removed in a disjunct
> 	aren't physically destroyed if a later disjunct needs them, and to
> 	make sure that at entry into a non-first disjunct, all the memory
> 	allocated since the entry into the disjunction is reclaimed instantly.
>
> compiler/commit_gen.m:
> compiler/code_info.m:
> 	The protection against destruction offered by a disjunction disappears
> 	when a commit cuts away all later alternatives in that disjunct, so we
> 	must undo that protection. We therefore surround the scope of a commit
> 	goal with goal that achieves that objective.
>
> 	Add some new utility predicates to code_info, and export some existing
> 	utility predicates for use by the modules above.
>
> compiler/continuation_info.m:
> 	Extend the type that describe the contents of stack slots to allow it
> 	to describe the new kinds of things we can now store in them.
>
> 	Rename the function symbols of that type to eliminate some ambiguities.
>
> compiler/code_gen.m:
> 	Preserve the set of variables live at the start of the goal
> 	(before the pre_goal_update updates it), since the region operations
> 	need to know this.
>
> 	Leave the lookup of AddTrailOps (and now AddRegionOps) to the specific
> 	kinds of goals that need it (the most frequent goals, unify and call,
> 	do not). Make both AddRegionOps and AddRegionOps use a self-explanatory

s/AddRegionOps/AddTrailOps/

> 	type instead of a boolean.
>
> compiler/lookup_switch.m:
> 	Conform to the change to AddTrailOps.
>
> 	Fix some misleading variable names.
>
> compiler/options.m:
> 	Add some options to control the number of stack slots needed for
> 	various purposes. These have to correspond to the sizes of some C
> 	structures in the runtime system. Eventually these will be constants,
> 	but it is handy to keep them easily changeable while the C data
> 	structures are still being worked on.
>
> 	Add an option for optimizing away region ops whereever possible.
> 	The intention is that these should be on all the time, but we
> 	will want to turn them off for benchmarking.

That looks okay.

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



More information about the reviews mailing list