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

[Nancy Mazur]

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

Fully agree. 

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

of course. 

> But otherwise that sounds 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.

Okay... after looking at the .opt files, they do seem interesting even
for my purposes (having the type-definitions, nice nice)... 
But by putting in my MCFLAGS --infer-structure-reuse, each of those
passes redoes the structure-reuse analysis... and that's a bit too much,
structure-reuse analysis not really being a light-weight process.... 
So anyway, `ideal' for me would be:
	- one small pass for the .opt files (can be avoided though)
	- and only one pass for .trans-opt, and .c (the analysis does
	  not only produce a trans-opt, but also a fully annotated HLDS,
	  for which it would be too much of a burden to re-annotate again
	  another time).

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

The trans-opt's are now only used for termination analysis, no? 
And if I understand it right, termination analysis does not annotate
in any way the HLDS, just verifies termination, which then indeed 
explains the 3 phases? 
So perhaps it would be indeed a good idea to have a new kind of
optimization-interface-files, which follows the scheme sketched above instead?
Okay... I'll try to do it... any inspiration for an apropriate file-extension?
I'll try to inspire my changes on the way trans-opts are dealt with... 

Nancy


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