[m-dev.] Bug 321

[Paul Bone]

On Fri, Feb 21, 2014 at 08:58:58PM +1100, Zoltan Somogyi wrote:
> 
> 
> On Fri, 21 Feb 2014 18:16:52 +1100, Paul Bone <paul at bone.id.au> wrote:
> > So I looked at readelf(1) dump of libmer_std.so's symbol table.
> > get_determinism/2 is exported globally and wrap_success_or_failure/2 is
> > exported locally.
> 
> I think you mean to say that wrap_s_or_f is local to its defining object file.

Yes, 'exported' is the wrong word here.

> > Both are declared and defined in the implementation section of the exception
> > module.  So now I want to know why is one being treated differently.
> > 
> > The relevant code seems to be on line 2186 of compiler/intermod.m, where the
> > compiler performs a fixpoint analysis so that it knows what else needs to be
> > opt-exported.  Searching further (line 289) I find should_be_processed/8
> > which appears to determine if a predicate should be opt-exported or not,
> > I'm not sure as comments are scarce.
> > 
> > Is there anyone familiar with this part of the compiler?  My clues are the
> > above, plus wrap_success_or_failure takes a higher order argument and is
> > part of a lambda expression itself, during compilation (in the HLDS) it
> > appears to be partially applied.
> > 
> > One specific question I have is how does the compiler decide between:
> >     + opt-exporting a predicate
> >     + making a predicate available to another module because a caller is
> >       opt-exported and this predicate is otherwise local.
> >     + leaving the predicate local.
> > 
> > I haven't found the code for the second case.
> 
> I think the bug is likely to be precisely the absence of code
>  for the second case.

I'm not sure/very worried about this possibility.  It begs the question "How
does this work all rather than work intermittently?" 

> I don't think you want to hear this, but I am pretty sure that
> the underlying reason for this bug is that the import_status type
> tries to encode far too many things at once. Some are relevant to
> types; some to unify predicates; some to other preds. Some are
> about location of definition, some are about visibility to Mercury code
> in other modules, some are about visibility to target code in other
> modules, and some are about visibility to submodules. The space
> of possible combinations is very large, but it is not fully covered.
> In this case, an import_status  ought to be able to say
> "this predicate is not callable by code in other Mercury modules,
> but it is called from a local predicate that has been made available
> for inlining by other modules, so its target code needs to be
> accessible from other modules", but it cannot.
> 
> Some years ago, I drew up two proposals for replacements
> for the import_status type. I think there was discussion
> of those proposals on a mailing list (m-dev or m-rev), but
> I am not sure; I am sure that neither proposal was actually
> implemented. Anyway, here are my files containing the two
> proposed sets of types to replace import_status. I think
> replacing import_status with either of these would be
> a significant improvement in the reliability of our handling
> of import and export. Unfortunately, it would also be
> a large amount of work. Someone would have to look
> at all current code that handles values of type import_status,
> and rethink exactly what the right thing to do in each case is.
> We currently have a bunch of utility predicates for testing
> this property or that of an import_status; all those calls
> would have to be looked at again. Most will probably be
> ok (and should be replaceable by simple unifications)
> but some won't.
> 

Thanks.  I'll take a look and weigh up how important it is to solve this
problem now.


-- 
Paul Bone