[m-dev.] .opt files for intermodule analysis

Julien Fischer juliensf at csse.unimelb.edu.au
Wed Feb 13 15:08:26 AEDT 2008


On Wed, 13 Feb 2008, Peter Wang wrote:

> Review/feedback required on this idea.
>
> The idea is to add optimisation interface files for the
> `--intermodule-analysis' option (currently called .analysis_opt files in
> my workspace).  The content of these files would be exactly the same as
> the initial contents of an .opt file.
>
> (1) intermodule inlining, higher order specialisation, etc. will work
> with --intermodule-analysis, with minimal effort.  Those passes wouldn't
> benefit from being modified to use the analysis framework anyway (I think).

Well, they defintely won't benefit from things like clauses and type
definitions being in the .analysis files; they may benefit from
information about where to inline or higher-order specialise being put
in the .analysis files.

> (2) CTGC requires the definitions of imported abstract types.  Since
> .opt files already do everything we need, just reuse the same system.
>
> The reason for not just reusing .opt files is that when you use
> --intermodule-optimisation, exception analysis (etc.) will append their
> own analysis results into them.  With --intermodule-analysis those
> results should be in .analysis files, so there is potential for
> conflicting results or getting results from the wrong place.

I don't see why these two mechanisms need to be compatible with each
other.  Specifically, if --intermodule-analysis is enabled then
exception analysis and friends should just not write analysis pragmas
out to the .opt files.

> An alternative would be to separate the current .opt files into two,
> say, .opt0 and .opt.  .opt0 files would contain only the information
> which can be shared between `--intermodule-analysis' and
> `--intermodule-optimisation'.  Making an .opt file would imply making a
> .opt0 file (similarly for reading) but not the other way around.  I
> think I like this idea better.

Given that once --intermodule-analysis is working for the major
optimisations we will be getting rid of --intermodule-optimisation
anyway, this doesn't seem to be worth it.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list