[m-dev.] [CTGC] conflict options ?

[Nancy]

(sorry for the previous empty reply... darn.. bad monday morning).

> With transitive intermodule optimisation it should actually be performed
> *three* times, since transitive intermodule optimisation implies intermodule
> optimisation.
> 
> The current processing for analysing a module foo, say with termination or
> exception analysis, is as follows:
> 
> (1) analyse foo based only on the information in foo.m ==> foo.opt
> 
> (2) analyse foo again based on the information in foo.m, in any .opt
>     files and *some* of the .trans_opt files (**) ==> foo.trans_opt
> 
> (3) compile foo again using the information from the .opt and .trans_opt
>      files and this time generate code ==> foo.{c,java,il}
> 
> (**) exactly which .trans_opt files depends on how the compiler decides
>      to break any cycles in the module dependency graph.
> 
> Step (1) corresponds to `--make-optimisation-interface', step (2) corresponds
> to `--make-transitive-optimisation-interface' and step (3) corresponds
> to `--compile-to-c'.

Many thanks for this explanation! It does clarify a lot to me... thx!

> If you're only performing two analysis passes then the analysis results (at
> least those across module boundaries) are probably not as accurate as they
> could be.  (You also need to modify mercury_compile.maybe_write_optfile/7 in
> order to produce the optimisation interface, i.e. the .opt file).
> 
> 
>>In fact, what I would prefer is that structure sharing analysis is only
>>performed when compiling to C, with the side-effect of generating a
>>trans-opt file (or something alike) dumping the information of all the
>>exported predicates/functions.
> 
> 
> Writing out the results when generating C code is too late though - you
> want the analysis results for all imported procedures *before* you start
> doing that.
> 
> 
>>In this way, structure sharing analysis would only be performed once (the
>>analysis is not cheap), and the results are immediately available to the
>>reuse analysis. Also, as far as structure reuse analysis is concerned, that
>>too needs to generate trans-opt information, but that one is really only
>>useful if and only if compiling to c (or some other low-level
>>representation).
>>
>>Any thoughts on this?
>>
> 
> 
> My immediate thought is that you should just make things work with the current
> intermodule analysis framework no matter how slow it is (i.e. even if it
> does currently require two or three analysis passes).  At the moment it is
> more important to merge the CTGC code onto the main branch; we can deal with
> improving the performance of it after that.

Yes I know ;-) I just wanted to find out the apropriate places to fit in 
the analyses at this current moment...

Thanks,
Nancy


> We are currently in the process of moving to a new intermodule analysis
> framework, the --intermodule-analysis option (you may have seen posts about
> this on mercury-reviews?).  When that is finished it should allow us to do
> a better job of avoiding unnecessary re-analysis.

> 
> Cheers,
> Julien.
> --------------------------------------------------------------------------
> 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
> --------------------------------------------------------------------------


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

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