for review: deforestation [3/4]

[Fergus Henderson]

On 19-Feb-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 			%
> 			% If we did a generalisation step when creating this
> 			% version, we need to modecheck to propagate through
> 			% the new insts. If this causes mode errors, don't
> 			% create the new version. This can happen if a 
> 			% procedure expected an input to be bound to a 
> 			% particular functor but the extra information
> 			% was generalised away.
> 			%

Hmm... couldn't the generalization step change the operational semantics?
Couldn't it for example transform a program which terminates into one that
doesn't?  If so, then surely this is unacceptable.

I think it could, if the program makes use of the C interface,
or if we ever allow different definitions for different modes
of Mercury predicates or functions.

> 	% Attempt to move irrelevant goals out of the conjunction.
> 	% This does a safe re-ordering that is guaranteed not to require
> 	% rescheduling of the conjunction, since it does not reorder goals
> 	% that depend on each other. 
> 	% We prefer to move goals forward out of the conjunction so that
> 	% they can participate in deforestation with goals later in the
> 	% conjunction. Constraint propagation should be run later to 
> 	% push goals backwards to counter any efficiency loss.
> :- pred deforest__reorder_conj(deforest_info::in, deforest_info::out,

Hmm, we don't have constraint propagation yet...
so I think that probably warants an XXX?

> 		list(hlds_goal)::out, list(hlds_goal)::out, 
> 		pd_info::pd_info_di, pd_info::pd_info_uo) is det.
> 
> deforest__reorder_conj(DeforestInfo0, DeforestInfo, 
> 		BeforeIrrelevant, AfterIrrelevant) -->
> 	pd_debug__message("Reordering conjunction\n", []),
> 	{ DeforestInfo0 = deforest_info(EarlierGoal, EarlierBranchInfo, 
> 			BetweenGoals0, LaterGoal, LaterBranchInfo,
> 			DeforestBranches) },
> 
> 	pd_info_get_module_info(ModuleInfo),
> 	pd_info_lookup_bool_option(fully_strict, FullyStrict),
> 
> 		% Favor moving goals backward to
> 		% avoid removing tail recursion.
> 	deforest__move_goals(deforest__can_move_goal_backward, ModuleInfo, 
> 		FullyStrict, BetweenGoals0, [], RevBetweenGoals1, EarlierGoal, 
> 		[], RevBeforeIrrelevant),
> 
> 	deforest__move_goals(deforest__can_move_goal_forward,
> 		ModuleInfo, FullyStrict, RevBetweenGoals1, 
> 		[], BetweenGoals, LaterGoal, [], AfterIrrelevant),

Hmm, the comment here seems to be at odds with the comment above.

> 	pd_util__simplify_goal(simplify(no, no, no, yes, yes, yes, yes, yes),
> 		Goal2, Goal3),

Here's another place where it would be better to use variables to
explicitly name the arguments.

> pd_cost__goal(pragma_c_code(_, _, _, _, _, _, _) - _, Cost) :-
> 	pd_cost__stack_flush(Cost).

The cost is higher for may_call_mercury pragma c_codes
than for will_not_call_mercury ones.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.