View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0000564 | mercury | Bug | public | 2022-09-08 14:27 | 2022-09-08 15:35 | ||||||||
Reporter | wangp | ||||||||||||
Assigned To | |||||||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||||||
Status | new | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0000564: unnecessary use_module in .opt files | ||||||||||||
Description | I was trying to figure out why a seemingly small change to one module causes a project-wide recompilation when developing with intermodule module optimisation enabled. For the attached test case, mmc --make-opt-int fib.m produces: :- module fib. :- use_module builtin. :- use_module int. :- use_module io. :- use_module map. :- use_module private_builtin. :- func fib.fib(int) = int. :- mode fib((builtin.in)) = (builtin.out) is det. :- pragma inline(func((fib.checked_fib)/1)). fib.checked_fib(V_3) = V_4 :- ( if V_5 = 40 : int, int.(V_3 >= V_5) then V_4 = -1 : int else V_4 = fib.fib(V_3) ). I don't see the need for: :- use_module io. :- use_module map. The io module is only used by a predicate not exported or opt-exported from fib.m. The map module is not used at all. Not sure about private_builtin either. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|
Notes | |
zs (developer) 2022-09-08 15:35 |
Unfortunately, this is not so much a bug, as an as-yet-unimplemented feature, because at the moment, we just generate a use_module declaration for *every* module imported by the module whose .opt file we are creating, *regardless* of whether it is needed or not. See the XXXs in intermod.m starting at line 1386. I think the reason for this non-attempt was that originally, .trans_opt files used to be written out piecemeal; each analysis pass, after it was run, appended its results to that file. This made it complicated to find out up front which modules would be needed, and writing out the use_modules at the end could have screwed up the then-rigid ordering requirements of the make_hlds pass. Such considerations would have affected .opt files as well, because .opt files are also written out in two pieces by two separate algorithms, as explained by the comment starting on line 58. However, the above is speculation, since I am not intermod.m's original author. As for why builtin and private_builtin are in the .opt file: they are *always* implicitly imported and used respectively in every module, whether needed or not, and intermod.m blindly copies them to the .opt file. |