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

[Nancy]

Julien Fischer wrote:
> On Fri, 3 Feb 2006, Nancy wrote:
> 
> 
>>but I'm still left a bit confused.. (and thinking out loud for the
>>moment) ... see below...
>>
>>
>>>The reason that's happening is because --make-trans-opt is overriding
>>>-c and it looks your analysis is only being run when compiling to C,
>>>not when building the .trans_opt files.  In order to do the latter
>>>you will need to modify mercury_compile.maybe_write_optfile/7 and
>>>mercury_compile.output_trans_opt_file/5.  I suggest having a look
>>>at how termination analysis is handled in mercury_compile.m since it
>>>also uses transitive intermodule optimisation.
>>
>>So I did have a look at the mentioned predicates, and well, the
>>structure sharing analysis (to be submitted for review soon now) works
>>well it seems, also with intermodule optimisation... but here is what I
>>am confused from:
>>
>>When doing a mmake of a small program consisting of a couple modules,
>>the structure sharing analysis is performed twice each time:
>>- once to create the trans_opt file
>>- once in the process of compiling to c.
>>And with the current shape of the things both seem to be absolutely
>>necessary:
>>- the entries in the trans_opt are needed when compiling other modules;
>>- and when compiling to c, many new predicates are generated, and they
>>too must be analysed as the results are needed for the subsequent
>>structure reuse analysis to be as precise as possible.
> 
> 
> 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'.
> 
> 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.
> 
> 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
--------------------------------------------------------------------------