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

[Fergus Henderson]

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

You don't _have_ to generate a new trans_opt file simply because
you've made a new reuse, do you?

Maybe you should explain in a bit more detail what the struct reuse
inference pass does, and what stuff you're adding to the .trans_opt files.

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

There are several alternatives that I can think of:

	(a) use the existing trans-opt system
	    (drawback: requires more passes than you want)

	(b) change the existing trans-opt system to do what you want
	    (drawback: the reduced precision might be bad for
	    termination analysis)

	(c) add a new trans-opt system, in addition to the existing one,
	    with a different file extension
	    (drawback: increases complexity of the whole system; and
	    could make things very slow indeed if you want to do both
	    structure reuse inference and termination analysis at the
	    same time, since you might end up using both trans-opt
	    systems)

	(d) add a new trans-opt system, but use the same file extension:
	    make the way .trans_opt files are used depend on a compilation
	    option.
	    (drawback: increases complexity of the whole system,
	    though in a different way than (c);
	    and might be harder to handle in Mmake)

I'm not sure which of these would be best.

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