[m-dev.] Bug 321

[Zoltan Somogyi]

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.

> 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 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.


Zoltan.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: STATUS1
Type: application/octet-stream
Size: 3006 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20140221/8f2ff47f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STATUS2
Type: application/octet-stream
Size: 3808 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20140221/8f2ff47f/attachment-0001.obj>