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

[Julien Fischer]

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