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

[Nancy Mazur]

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

Yes... in most cases I will have to generate a new trans_opt file.. 
The information I'm storing in these files contains info expressing conditions  
which have to be satisfied by callers of the concerned predicate
in order for the reuse to be safely allowed in such cases... 
So a priori, each new reuse can introduce some new conditions, which
will have to be present in the .trans_opt.. or else, the reuse-system
will become unsafe... 

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

for the reuse it adds conditions which have to be fulfilled by each caller
of the exported predicates... 
it also contains the possible aliases that each procedure might create..
(but that presents doesn't present the same problem as the reuse-info does).

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

is that really a problem? Both analyses are separate anyway? 

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

I'll have some further thinking... perhaps coming up with some other
ideas... 

many thanks already,
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
--------------------------------------------------------------------------