[m-dev.] for review: last call modulo constructors [1/3]

[Andrew Bromage]

G'day all.

David Matthew Overton wrote:

> Could you please review this, since you are familiar with the alias
> branch.  Anyone else who wants to have a look, feel free.

Note: My review of the changes to code generation won't be so great,
since I'm not so familiar with that bit.  I'll try my best...

On the log message:

You should mention that accurate GC and trace debugging may be broken
by using lco, just so that nobody tries it.

> compiler/inst.m:
> 	Add an argument to `free' insts to say whether or not they are
> 	aliased.
> 

> compiler/common.m:
[and more]
> 	Add an argument to `free' insts to say whether or not they are
> 	aliased.

I realise disk space in the repository isn't that tight, but you could
do some log merging here if you want to.

> Index: compiler/call_gen.m
> ===================================================================
> RCS file: /home/staff/zs/imp/mercury/compiler/call_gen.m,v
> retrieving revision 1.113.4.8
> diff -u -r1.113.4.8 call_gen.m
> --- 1.113.4.8	1998/06/05 08:42:48
> +++ call_gen.m	1998/06/22 01:02:35

> +		( Mode = top_in ; Mode = ref_in )

> +		( Mode = top_out ; Mode = ref_out )

These patterns happen a lot.  I'm wondering if it might be worth making
an predicate to do this test in case more modes are added.  Is that
likely to happen?  Would free(aliased_many) require a new mode, for
example?

> Index: compiler/code_exprn.m
> ===================================================================
> RCS file: /home/staff/zs/imp/mercury/compiler/code_exprn.m,v
> retrieving revision 1.51.4.5
> diff -u -r1.51.4.5 code_exprn.m
> --- 1.51.4.5	1998/06/05 08:43:04
> +++ code_exprn.m	1998/06/22 01:28:00

> @@ -254,9 +288,27 @@

> +% Locations where the value needs to be placed, Each lval in a
s/Each/each/
> +% set(lval) should point to the same place.  The bool is yes if the
> +% value is already in this location, otherwise it is no.


> +:- pred code_exprn__remove_rval_from_lvals(rval, set(lval), set(lval)).
> +:- mode code_exprn__remove_rval_from_lvals(in, in, out) is det.
> +
> +code_exprn__remove_rval_from_lvals(Rval, Lvals0, Lvals) :-
> +	( Rval = lval(Lval) ->
> +		set__delete(Lvals0, Lval, Lvals)
> +	;
> +		Lvals = Lvals0
> +	).

Should the `else' case be a call to error/1 here?

Part 2 follows...

Cheers,
Andrew Bromage