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

[Nancy]

Hi Julian,

(sorry about the size of the attachments... didn't think about it)

>>I have a quite odd situation with the mercury options.
>>
>>I've added a new option "structure-sharing" (long option:
>>data_structure_sharing_analysis) (cf. the attached options.m file).
>>As structure sharing analysis depends on trans-opt files, it seems
>>logical to me to add the line:
>>
>>option_implies(data_structure_sharing_analysis,
>>      make_transitive_opt_interface, bool(yes), !Globals),
>>
>>in handle_options.m (see attach.).
>>
> 
> 
> This implication is incorrect.  The option
> 'make_transitive_opt_interface' tells the compiler to build the
> .trans_opt file on this invocation and then stop.  It's not the same
> as -c (--compile-to-c) which tells the compiler to generate code.
> 
> I suspect what you probably meant there was:
> 
> 	option_implies(data_structure_sharing_analysis,
> 		transitive_optimization, bool(yes), !Globals)

Yes, thanks...

> but even that IMHO is unnecessary.  It should be possible to run the
> structure sharing analysis without enabling transitive intermodule
> optimization (it may not be very useful to do so, although in the case
> of small test cases, like the one below, it means you can check things
> are working just by compiling with -c).

well, I can agree to some extent...

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

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

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

Regards,
Nancy


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