[m-dev.] compiler not building with --intermodule-optimization

[Julien Fischer]

Hi,

The compiler is not currently building when --intermodule-optimization is
enabled, due to:

clause_to_proc.m:056: In module `check_hlds.clause_to_proc':
clause_to_proc.m:056: warning: module `hlds.vartypes' has a
clause_to_proc.m:056: `:- import_module' declaration, but is not used
clause_to_proc.m:056: anywhere in the module.

The fix is trivial; however, why is the warning only being triggered
when --intermodule-optimization is enabled?

Julien.

[Zoltan Somogyi]

Post by Julien Fischer
The compiler is not currently building when --intermodule-optimization is
clause_to_proc.m:056: warning: module `hlds.vartypes' has a
clause_to_proc.m:056: `:- import_module' declaration, but is not used
clause_to_proc.m:056: anywhere in the module.
The fix is trivial; however, why is the warning only being triggered
when --intermodule-optimization is enabled?

I have a strong hunch that the reason is that the code that
generates that warning does not know about the expansion
of equivalence types.

Clause_to_proc.m calls two predicates whose arguments
include the type "vartypes". Since vartypes.m defines this type,
it is not unused, and without intermodule optimization,
the compiler sees that.

*With* intermodule optimization, the compiler expands out
the type "vartypes" to its definition, which is
"map(prog_var, mer_type)". This expansion removes
from the HLDS any trace of anything defined in vartypes.m,
and this leads to the warning.

I think the type expansion passes (both equiv_type.m and
equiv_type_hlds.m) both have some code to record
the stuff they use from other modules, but either they
don't record the right stuff, or unused_modules.m
does not pay attention to it.

The fact that the compiler can happily compile clause_to_proc.m
without knowing the definition of vartypes shows that
unused_imports.m takes, um, a "generous view" of what
it considers used. This is a second, unrelated problem,
but harder to fix, because it requires unused_imports.m
to know exactly what occurrences of item names (e.g. type names)
require the compiler to know the definition of the
named item, and which do not impose such a requirement.

Fixing either problem should make the above warning
disappear, but it would be nicer to fix both.

Zoltan.

[Julien Fischer]

Post by Zoltan Somogyi
Fixing either problem should make the above warning
disappear, but it would be nicer to fix both.

In the interim, do you have any objection to me disabling the warning
for that module (and any others so affected). This is preventing us
from bootchecking the compiler at higher optimization levels.

Julien.

[Zoltan Somogyi]

Post by Julien Fischer
In the interim, do you have any objection to me disabling the warning
for that module (and any others so affected). This is preventing us
from bootchecking the compiler at higher optimization levels.

Try deleting the import first; for clause_to_proc.m, that should fix
the problem. If that doesn't work, then I don't object to
disabling the warning.

Zoltan.

[Julien Fischer]

Post by Zoltan Somogyi

Post by Julien Fischer
In the interim, do you have any objection to me disabling the warning
for that module (and any others so affected). This is preventing us
from bootchecking the compiler at higher optimization levels.

Try deleting the import first; for clause_to_proc.m, that should fix
the problem.

That was the trivial fix I was referring to. (It does work BTW.) I'll
look at constructing a cut-down instance of problem for the test suite.

Julien.