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

[Nancy Mazur]

> 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:
> > > > [Fergus wrote:]
> > > > 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.
> > 
> > Okay..... but then I don't get it why it's split in 3 phases
> > and not only 2
> 
> The reason for that is to improve the amount of information available
> during code generation in the case there are cyclic dependencies.
> 
> With transitive intermodule optimization, the dependencies are like this:
> 
> 	foo.opt depends only on foo.m (and the .int* files, of course)
> 
> 	foo.trans_opt depends on
> 		- the .opt files for ALL of foo's imported modules
> 		- the .trans_opt files for SOME of foo's imported modules,
> 		  namely those which occur before foo in the ordering
> 
> 	foo.c depends on
> 		- the .opt files for ALL of foo's imported modules
> 		- the .trans_opt files for ALL of foo's imported modules
> 
> The reason why we need three passes is because we have defined the
> dependencies in this way.  The .c file can't be generated in the
> same pass that generates the .trans_opt file since in the general case
> we may not have read in all the .trans_opt files for imported modules
> (indeed we can't read them in during that pass, since they may not have
> been generated yet).
> 
> The reason that we decided that the foo.c file should depend on
> the .trans_opt files for ALL of foo's imported modules was to
> increase the precision of the information available during code
> generation in cases involving cyclic module dependencies.
> That decision may perhaps not have been optimal, and so you might
> want to reconsider it.

Hmmm.. okay... it's all getting way clearer to me now.. many thanks... 

And within this explanation, it also gives another reason why I can't
use the same trans-opt system:
	my foo.opt : dependencies as above.. 
	my foo.trans_opt: relies on all .opt files, and on as much
		.trans_opt files of foo's imported files as possible
		(with the problem of cyclic module dependencies, for which
		no .trans_opt files are available)
	a separate pass for foo.c could then be seen as an extra
	fixpoint-pass of the reuse-analysis: extra information, more
	precision, and perhaps a new reuse, and whopla: a new trans_opt
	should perhaps be made... and we're back to zero... 
So it's really in accordance to what has been derived in the .trans-opt
phase, that the foo.c should be generated... 

So I'm back to my initial question.. how to solve this? 
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
--------------------------------------------------------------------------