[m-dev.] option-finetuning (generating trans-opts)

[Fergus Henderson]

On 12-Sep-2000, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> I'm having a bit of problems generating the trans-opt files as I would
> like to. I have introduced two new options to the mercury compiler:
> 	--infer-possible-aliases :: activates possible aliases analysis
> 	--infer-structure-reuse  :: activates structure reuse analysis
> (structure reuse does not go without possible aliases, yet I've 
> allowed the two options, in case one day the possible aliases analysis
> could be used for other purposes than structure reuse). 

OK, sounds good.  Just make sure that --infer-structure-reuse implies
--infer-possible-aliases. (I see below you have indeed done that.)

If --infer-possible-aliases is not useful except to enable
--infer-structure-reuse, then probably the user documentation
should only document the latter.

> Now, each of these analyses dumps some output into an interface
> file, as I understood, the trans-opt files are ideal for that purpose. 

Well, they are certainly the closest thing we have to what you want.
Whether they are ideal for your purposes is another question.
It may be that our existing infrastructure simply does not provide
anything which is ideal for your purposes.

> Now I'd like to finetune the settings of my options to obtain the
> following: 
> 	(1) whenever structure reuse is activated, possible aliases
> 	  must be analysed too
>
> 	(2) whenever structure reuse or possible aliases is enabled, trans-opt's
> 	  must be generated and used (giving a warning when for some
> 	  files they are not present)
>
> 	(3) and finally, c-files should be generated at the end, as usual
> 	  (so that o-files can be made, and eventually an
> 	  executable is obtained)... 

Well, whether or not C files are generated should depend on
what other options the user gives.  If the user invokes mmc with
"--error-check-only", or "--target il", or various other options,
or likewise invokes mmake with target `foo.err' rather than `foo',
then C files should not be generated.

But otherwise that sounds fine.

> So this is what I came up with:
> 
> in handle_options__postprocess_options_2/9, just after some settings
> regarding termination analysis, I've been trying the following:
> 
>         option_implies(verbose_check_termination, check_termination,bool(yes)),
>         option_implies(check_termination, termination, bool(yes)),
>         option_implies(check_termination, warn_missing_trans_opt_files,
>                 bool(yes)),
> 	
>         option_implies(infer_structure_reuse, infer_possible_aliases,
>                 bool(yes)),
>         option_implies(infer_possible_aliases, warn_missing_trans_opt_files,
>                bool(yes)),
>         option_implies(infer_possible_aliases, transitive_optimization,
>                bool(yes)),
> 
>         option_implies(make_transitive_opt_interface, transitive_optimization,
>                 bool(yes)),
>         option_implies(transitive_optimization, intermodule_optimization,
>                 bool(yes)),
>         option_implies(use_trans_opt_files, use_opt_files, bool(yes)),

That all looks fine.

> This combination gave me the most satisfying results (trans-opts generated, 
> c-files generated), but with the effect that each module is treated 
> a couple of times, and thus analysed a couple of times (which is absurd)?

This is inherent in the current design for how trans-opt files work.

In the current design, the generated C code depends on the .trans_opt
files, and the .trans_opt files depend on the .opt files.

The advantages of the current design are (1) that you get fairly good
propagation of information, even for cases where there is some
mutual recursion between modules, and (2) you never have to build
the same file twice in a single build, so the number of passes is
bounded, and it interacts nicely with Make.  However, the current
design does have some significant disadvantages, as you have noted.

> So as you can see, c-files are there, trans-opt's are there, but it
> takes three mmc-passes to get there? Three analyses?

One to build the .opt files, one to build the .trans_opt files,
and then one to build the .c files.

> Can't I avoid this?

Well, basically the only way to avoid this would be to redesign the
way trans-opt files work.  That might well be a good idea!

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------