[m-dev.] ground->clobbered argument modes

[Fergus Henderson]

On 04-Aug-1999, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> There are a couple of modules in the compiler (pd_info.m, typecheck.m)
> which use `ground' instead of `unique' for initial insts because aliasing
> doesn't work properly. They still use `clobbered' for the final insts,
> resulting in the mode of some arguments of some predicates being
> `ground -> clobbered'. This can cause problems when rerunning mode
> analysis in the alias branch after some calls have been inlined.
> 
> In the clause for sc1/4 below, if the call to sc_get/3 is inlined and the
> call to sc_set/3 is not inlined, a mode error results. There appears
> to be an uncaught mode error in sc_get/3 -- the first argument (which is
> live after the predicate returns) is aliased to the first field of the second
> argument, for which the final inst in the argument modes is `clobbered'.
> 
> Any ideas on how mode analysis is supposed to treat this case?

Well, MHO is as follows:

	If the final inst is `clobbered', this indicates a constraint
	on the caller -- the caller must ensure that there will be no
	further references to that argument.  The constraint imposed
	by `clobbered' on the final inst is similar to that imposed by
	`unique' on the initial inst, but stronger.  The compiler must
	check that the caller satisfies this constraint.
	
	This means that a mode like `ground -> clobbered' is not very useful.
	Since the constraints implied by `clobbered' on the final inst
	imply the same constraints that would be implied by `unique'
	on the initial inst, `ground -> clobbered' should have exactly
	the same semantics as `unique -> clobbered'.

According to this analysis, the code for sc_get/3 is OK;
the mode checker should allow that.  Instead, the uncaught mode error
in this module is in the call to sc_set/3 in sc2/4; this code should
be illegal because sc2/4 calls sc_set/3 with an argument which is still
(in part) live, even though the final inst is `clobbered'.
When checking if a variable is live, mode analysis needs to also check whether
any of the variables that it (or any part of it) is aliased to are live.

Note that even if we disallowed modes like `ground -> clobbered' or
changed the rules so that sc_get/3 was not considered mode-correct,
mode analysis would still have to do the more complicated liveness
calculation described above, in order to resolve overloading between
`di' and `ui' properly in cases similar to this one.

For example:

	:- mode like_sc2(in, out, di, out) is det.
	like_sc2(A, B, Foo0, Foo) :-
		Foo0 = foo(B, _, _),
		Foo1 = Foo0,
		like_sc_set(A, Foo1, Foo).

	:- mode like_set(in, di, uo) is det.	% destructive
	:- mode like_set(in, ui, uo) is det.	% makes a fresh copy

Here the call to like_sc_set should call the version which has a `ui'
mode for the second argument, rather than the version which has a `di'
mode for that argument.

> One possible fix would be to unify the uniqueness (but not the bindings)
> of the final insts in the argument modes with the final insts of
> the argument variables before calling inst_matches_final.

I'm not certain that I understand what you mean here -- perhaps you should
explain in more detail -- but at first glance I don't think that would work.
Consider the following example:

	:- mode foo(di, uo).
	foo(X, X).

The uniqueness of the final inst of the first argument is `clobbered';
if you unify the inst of `X' with that before calling inst_matches_final,
then `X' will have inst `clobbered', and so inst_matches_final will report
a mode error in the second argument.

-- 
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.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------