[m-dev.] diff: Reorganisation of inst types and operations
Andrew Bromage
bromage at cs.mu.oz.au
Wed Jul 23 12:23:09 AEST 1997
G'day.
In response to a diff from about a week ago, Fergus Henderson wrote:
> You need more detailed documentation of the rationale.
> Why will moving things into this new module reduce coupling?
Here's an updated log.
Cheers,
Andrew Bromage
Estimated hours taken: 15
Reorganisation of modules to do with the inst data type.
This is actually the first installment of the alias tracking mode
checker in disguise. A very good disguise. The rationale for
this reorganisation is to reduce coupling in the part of the mode
checker which is _not_ in this change (ie most of it).
Alias tracking requires a new kind of inst, alias(inst_key), where
an inst_key is a handle on some other sub-inst. With it goes a
data structure in which to store dereferenced insts and all the
operations which go with it. This code will go in the new module
inst.m.
The remainder of the reorganisation is a general cleanup: the
inst testing predicates (inst_is_*) have been moved out of
mode_util because they are not actually operations on modes at
all, and have been moved into inst_match. inst_match has then
been split because otherwise it would be 2000 lines long and
will get significantly bigger when aliasing is added. Roughly
speaking, any operations which create new insts from old ones
have been moved into a new module, inst_util while any operations
which test the values of insts remain in inst_match.
Also included are the removal of some NU-Prologisms since the
NU-Prolog version of the compiler is no longer supported. Two
changes here:
- Removal of some when declarations.
- A gross hack in inst_is_*_2, where two copies of
the same inst were passed into the predicate so that
one could be switched on. Thank NU-Prolog's lack of
common subexpression elimination.
compiler/inst.m:
New module which contains the data types inst, uniqueness,
pred_inst_info, bound_inst.
compiler/inst_util.m:
New module which contains predicates which perform mode
checking-like operations on insts.
Moved in:
abstractly_unify_inst, abstractly_unify_inst_functor
(from inst_match.m)
inst_merge, make_mostly_uniq_inst (from inst_util.m)
compiler/inst_match.m:
Moved out:
inst_merge, make_mostly_uniq_inst,
abstractly_unify_inst, abstractly_unify_inst_functor
(to inst_util.m)
Moved in:
inst_is_*, inst_list_is_*, bound_inst_list_is_*
(from mode_util.m)
Now exported:
unique_matches_initial/2, unique_matches_final/2
inst_contains_instname/3, pred_inst_matches/3
(They are required by inst_util.m, and they are
useful in their own right.)
compiler/instmap.m:
instmap_delta_lookup_var/3 reincarnated as
instmap_delta_search_var/3. The reason for this change is
that previously, instmap_delta_lookup_var simply returned
`free' if the searched-for var did not occur in the
instmap_delta. This is somewhat non-obvious behaviour.
instmap_delta_search_var/3 fails in such a situation.
compiler/mode_util.m:
Moved out:
inst_is_*, inst_list_is_*, bound_inst_list_is_*
(to inst_match.m)
(These are not really operations on modes.)
compiler/modecheck_call.m:
Moved in modecheck_higher_order_func_call/5, from modecheck_unify.m
compiler/modecheck_unify.m:
Moved out modecheck_higher_order_func_call/5, to modecheck_call.m
where it should have been all along.
compiler/prog_data.m:
Moved out the types inst, uniqueness, pred_inst_info,
bound_inst (to inst.m).
compiler/common.m:
compiler/cse_detection.m:
compiler/fact_table.m:
compiler/higher_order.m:
compiler/hlds_data.m:
compiler/hlds_goal.m:
compiler/hlds_out.m:
compiler/intermod.m:
compiler/liveness.m:
compiler/llds.m:
compiler/make_hlds.m:
compiler/mercury_to_mercury.m:
compiler/mode_debug.m:
compiler/mode_errors.m:
compiler/mode_info.m:
compiler/modes.m:
compiler/module_qual.m:
compiler/polymorphism.m:
compiler/prog_io.m:
compiler/prog_io_util.m:
compiler/prog_util.m:
compiler/simplify.m:
compiler/switch_detection.m:
compiler/unify_proc.m:
compiler/unique_modes.m:
Miscellaneous minor changes to cope with the above changes.
More information about the developers
mailing list