argument modes

[Andrew Bromage]

G'day all.

I'm Cc'ing mercury-developers here since this should probably go into
the archives.

On Fri, Dec 11, 1998 at 04:46:33PM EST, Simon Taylor wrote:

> > I've been working on merging the Aditi changes into the alias branch.
> > What is the role of the inst_table in the argument modes of procedures
> > and higher-order call goals? Why is it different to the inst_table for
> > the procedure?

David Overton replied:

> These inst_tables contain only information relevant to the arguments of
> the proc/higher-order call, e.g. aliasing between arguments.  They
> form part of the interface to the proc and should not contain any
> information about local variables.
> 
> I'm not quite sure why Andrew chose to have two separate inst_tables
> for each proc (one in the proc_info and one in the argument_modes),
> perhaps for efficiency reasons?

Basically, yes.

The design decision was taken at a time when I was having huge problems
with the sizes of inst_tables, which were growing like wildfire even in
relatively common kinds of procs.  It became obvious that when mode
checking a call with aliased arguments, the last thing you want to do
is rename apart all inst_keys used inside the body of the called proc.
You want to use only those which are declared in the argument modes.
(Especially for semantic reasons, since the "real" insts may be more
specific than the declared ones.)  So you either store away the
information once and use that, or you have some way to recompute it
cheaply on every mode check (and every recompute_instmap_delta).

Now think about how you'd the latter.  You'd have to find all of the
inst_keys, merged_insts, unify_insts and so on (remember this is
supposed to work for unify_procs too, which could easily have these
exotic insts in them) that are referenced from the "root set", which
are the argument modes.  This means a fixpoint iteration over the whole
inst_table in general.  It's more time-efficient just to store another
inst_table, and it's one less garbage collector that I had to write.

Cheers,
Andrew Bromage