[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:
> > > > 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.)

The latter would be more apropriate, but still not satisfying.. 
Some benchmarking and measuring should be needed to see what the
cost would be of that last pass where the .trans-opts are simply used. 
Intuitively I'd say it's too much, especially as the aliasing
information should be rethreaded through the HLDS (no reanalysis, of
course, but we simply need to know all the aliases at all the relevant
program points).. 
And as said.. the process is not light-weight, every extra unnecessary
operation should be avoided, I think?

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

It has the same problem as above, and it gives a bit of a dirty solution
feeling... 

wouldn't it all be cleaner the solution you gave initially: design
a new kind of trans-opts? As the behaviour of what my process needs
seems to be different from the behaviour originally intended wrt the
.trans_opt's? Or do you fear that this would involve too much work? 

Of course, the above solution is very fast to use... but in the long run?

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

Okay..... but then I don't get it why it's split in 3 phases
and not only 2, as code generation does rely on some information
collected during the trans-opt phase? How does it rely on that information?
Reading the trans-opts back in? Just like you described above? 
Hmm... I don't know.. I thought I started to understand the bits
around trans-opts.. but it gets messed up again ;-) 

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