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

[Fergus Henderson]

On 12-Sep-2000, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> [Fergus wrote:]
> > On 12-Sep-2000, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> > > 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.... 

Oh, I see.  If you don't mind so much that it does three passes, just
that it does three passes all of which do structure reuse analysis,
then that is easily fixed.  There are alternative variables to MCFLAGS
that specify which flags should be used for each pass, e.g.

	MCDFLAGS	flags to use when generating dependencies
	MCTOIFLAGS	flags to use when making .trans_opt files
	MCGFLAGS	flags to use when generating code

In particular, if you take --infer-structure-reuse out of MCFLAGS
and instead put it just in MCDFLAGS (needed since --infer-structure-reuse
implies --transitive-intermodule-optimization, which affects the
dependencies) and MCTOIFLAGS, then the structure reuse information
will only be generated when creating the .trans_opt files.

Of course if you want the structure reuse information to be used when
generating code then you will need to put some option in MCGFLAGS too,
perhaps --infer-structure-reuse.  (Or perhaps some option that just
says to use the information already computed and stored in the .trans_opt
file by the previous pass... would that work? I think that when
generating code, modules.m will not read in the .trans_opt file for
the module currently being compiled, so to make it work, you would
have to change that.)

Alternatively, rather than setting MCDFLAGS, MCTOIFLAGS, and MCGFLAGS,
you could just set MCFLAGS, and instead change mercury_compile.m so
that it doesn't invoke the pass to infer structure reuse if the
`--make-opt-int' (make_optimization_interface) option is set.
That is probably a better long-term solution.

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

That's correct.

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

Termination analysis does annotate the HLDS.
It sets the termination_info field in the proc_info,
which is used by simplify.m, which calls code_aux__goal_cannot_loop
to determine when certain optimizations are applicable.

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