[m-rev.] for post-commit review: "unused" eqv types

[Zoltan Somogyi]

On Tue, 10 Aug 2021 13:04:35 +1000, Peter Wang <novalazy at gmail.com> wrote:

> On Tue, 10 Aug 2021 12:07:35 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > +% - We could have equiv_type.m record, in every item in which it expands out
> > +%   a type equivalence (or, for the same reason, an inst or mode equivalence)
> > +%   defined in a given module, record the name of that module in a new field
> > +%   in that item. In this case, this would mean including the pred_table module
> > +%   in this new field in the pred decl item for module_info_get_preds.
> > +%   We would preserve the value of this field in the HLDS, e.g. in pred_infos.
> > +%   Then, when the code of this module references module_info_get_preds,
> > +%   the code generating unused module warnings would consider that reference
> > +%   to use not just the module that defines module_info_get_preds, but also
> > +%   all the modules recorded in the new "modules that defined expanded
> > +%   equivalences" field of its pred_info. And likewide for other entities
> > +%   that contain types, insts and/or modes that can be expanded.
> 
> Does the used modules need to be recorded per item?

Yes, I think so.

> unused_imports.m should only need to know which modules are used for
> expansions down to module-section granularity, I would have thought.

If module A imports module B, and some predicate p in module B
refers to a an equivalence type in module C, then A does NOT thereby
refer to module C if it does not call (or take the address of) predicate p.

If you agree with that, I will add this paragraph to the comment.

> > +%
> > +% - We could add to every alternative in the mer_type, mer_inst and mer_mode
> > +%   types a new field that records the set of modules that defined the
> > +%   equivalence types, insts or modes in its construction. I mean that if
> > +%   the programmer writes map(pred_id, pred_info), then this set would be
> > +%   empty, but if the prgrammer writes pred_table, then, when replacing it
> > +%   with map(pred_id, pred_info), equiv_type.m would include the pred_table
> > +%   module in this set. Every compiler pass *but* unused imports would
> > +%   of course ignore this extra argument.
> 
> Do we sometimes directly unify mer_types, mer_insts or mer_modes?
> I would be worried about, e.g. two identical types comparing unequal
> because one was written directly, and one was expanded.

Yes, that is a valid additional concern, and I will modify the comment
to mention it.
 
Thanks for the review.

Zoltan.