[m-dev.] for review: last call modulo constructors [1/3]
Fergus Henderson
fjh at cs.mu.OZ.AU
Wed Jun 24 00:56:54 AEST 1998
On 22-Jun-1998, David Matthew Overton <dmo at students.cs.mu.oz.au> wrote:
> diff -u -r1.35.4.9 hlds_pred.m
> --- 1.35.4.9 1998/06/05 08:44:42
> +++ hlds_pred.m 1998/06/22 01:02:56
:- type arg_info ---> arg_info(
arg_loc, % stored location
arg_mode % mode of top functor
).
>
> :- type arg_mode ---> top_in
> ; top_out
> - ; top_unused.
> + ; top_unused
> + ; ref_out
> + ; ref_in.
The comment above "mode of top functor" (which would perhaps have been
better placed above the definition of `arg_mode' rather than at its use)
is no longer accurate.
Please document the meaning of all of these different arg_modes.
> compiler/inst.m:
> Add an argument to `free' insts to say whether or not they are
> aliased.
> +:- type aliasing
> + ---> unique % No aliases.
> + ; alias. % An alias exists.
> + % ; alias_many. % Many aliases - XXX to be added later.
It might be useful to document here why you want to keep track of
which variables have aliases (perhaps mentioning the effect on code
generation).
Does `alias' mean exactly one alias? At most one alias? At least one alias?
I'm having some difficulty understanding how this is supposed to work.
Presumably whether or not a variable is aliased depends on what
else is in scope; so if X is aliased to Y, and then (as you traverse
down the goal) Y goes out of scope, then X is no longer aliased, right?
If so, does that mean that mode analysis must update all the
`free(alias)' insts whenever variables go out of scope?
--
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.
More information about the developers
mailing list