[m-dev.] option-finetuning (generating trans-opts)
Nancy Mazur
Nancy.Mazur at cs.kuleuven.ac.be
Tue Sep 12 19:47:05 AEDT 2000
Hi,
I'm having a bit of problems generating the trans-opt files as I would
like to. I have introduced two new options to the mercury compiler:
--infer-possible-aliases :: activates possible aliases analysis
--infer-structure-reuse :: activates structure reuse analysis
(structure reuse does not go without possible aliases, yet I've
allowed the two options, in case one day the possible aliases analysis
could be used for other purposes than structure reuse).
Now, each of these analyses dumps some output into an interface
file, as I understood, the trans-opt files are ideal for that purpose.
Now I'd like to finetune the settings of my options to obtain the
following:
(1) whenever structure reuse is activated, possible aliases
must be analysed too
(2) whenever structure reuse or possible aliases is enabled, trans-opt's
must be generated and used (giving a warning when for some
files they are not present)
(3) and finally, c-files should be generated at the end, as usual
(so that o-files can be made, and eventually an
executable is obtained)...
So this is what I came up with:
in handle_options__postprocess_options_2/9, just after some settings
regarding termination analysis, I've been trying the following:
option_implies(verbose_check_termination, check_termination,bool(yes)),
option_implies(check_termination, termination, bool(yes)),
option_implies(check_termination, warn_missing_trans_opt_files,
bool(yes)),
option_implies(infer_structure_reuse, infer_possible_aliases,
bool(yes)),
option_implies(infer_possible_aliases, warn_missing_trans_opt_files,
bool(yes)),
option_implies(infer_possible_aliases, transitive_optimization,
bool(yes)),
option_implies(make_transitive_opt_interface, transitive_optimization,
bool(yes)),
option_implies(transitive_optimization, intermodule_optimization,
bool(yes)),
option_implies(use_trans_opt_files, use_opt_files, bool(yes)),
This combination gave me the most satisfying results (trans-opts generated,
c-files generated), but with the effect that each module is treated
a couple of times, and thus analysed a couple of times (which is absurd)?
(see below for the detailed description of environment and one of the
tests).
All other combinations either resulted in c-files/no trans-opt files or
trans-opt files/ no c-files... and I'm a bit lost here.
I didn't bother until now... but as I'm cleaning up the whole structure
reuse analysis, I would like to solve this problem...
Any ideas? What am I missing here? 'Cause I really have been trying
every possible combination of options I thought might be related...
Many thx in advance,
Nancy
PS: I used to make use only of the --make-trans-opt option
(make_transitive_opt_interface), but then no c-files were generated,
with the effect that at each recompilation of a small testproject
involving several modules, everything gets recompiled/reanalysed
each time.
PS: using Pete's lmmake, with handle_options as above, and a Mmakefile
containing:
MCFLAGS = --infer-structure-reuse -d 11 -D ALL
This is what I get at my terminal:
[nancy at woolloomooloo]$ lmmake up_tree234.realclean
WORKSPACE = /home/nancy/mercury/intern/mercury
rm -rf up_tree234.dir
rm -f up_tree234.c up_tree234_init.c
rm -f up_tree234.s up_tree234_init.s
rm -f up_tree234.o up_tree234_init.o
rm -f up_tree234.pic_o up_tree234_init.pic_o
rm -f up_tree234.prof
rm -f up_tree234.err
rm -f up_tree234.base_schema up_tree234.derived_schema
rm -f up_tree234.date
rm -f up_tree234.date0
rm -f up_tree234.date3
rm -f up_tree234.optdate
rm -f up_tree234.trans_opt_date
rm -f up_tree234.int up_tree234.int2
rm -f up_tree234.int0
rm -f up_tree234.int3
rm -f up_tree234.opt
rm -f up_tree234.trans_opt
rm -f up_tree234.d
rm -f up_tree234.h
rm -f up_tree234.rlo
rm -f up_tree234 up_tree234.split up_tree234.split.a up_tree234.init
libup_tree234.a libup_tree234.so up_tree234.dep up_tree234.dv
[nancy at woolloomooloo]$ lmmake up_tree234.depend
WORKSPACE = /home/nancy/mercury/intern/mercury
mmc --generate-dependencies --grade asm_fast.gc --infer-structure-reuse -d
11 -D ALL up_tree234
[nancy at woolloomooloo]$ lmmake up_tree234
WORKSPACE = /home/nancy/mercury/intern/mercury
mmc --make-optimization-interface --infer-structure-reuse -d 11 -D ALL
up_tree234.m
up_tree234.m:001: In module `up_tree234':
up_tree234.m:001: warning: modules `assoc_list' and `list'
up_tree234.m:001: are imported in the interface, but are not
up_tree234.m:001: used in the interface.
mmc --make-transitive-optimization-interface --infer-structure-reuse -d 11 -D
ALL up_tree234.m
up_tree234.m:001: In module `up_tree234':
up_tree234.m:001: warning: modules `assoc_list' and `list'
up_tree234.m:001: are imported in the interface, but are not
up_tree234.m:001: used in the interface.
rm -f up_tree234.c
mmc --compile-to-c --grade asm_fast.gc --infer-structure-reuse -d 11 -D
ALL up_tree234.m > up_tree234.err 2>&1
mgnuc --grade asm_fast.gc -c up_tree234.c -o up_tree234.o
c2init --grade asm_fast.gc up_tree234.c > up_tree234_init.c
mgnuc --grade asm_fast.gc -c up_tree234_init.c -o up_tree234_init.o
ml --grade asm_fast.gc -o up_tree234 up_tree234_init.o \
up_tree234.o
up_tree234_init.o: In function `mercury_init':
up_tree234_init.o(.text+0xe1): undefined reference to `<predicate 'main'/2
mode 0>'
make: *** [up_tree234] Error 1
[nancy at woolloomooloo]$ ls up_tree234*
up_tree234.c up_tree234.o
up_tree234.d up_tree234.opt
up_tree234.dep up_tree234.optdate
up_tree234.dv up_tree234.trans_opt
up_tree234.err up_tree234.trans_opt_date
up_tree234.hlds_dump.11-structure_reuse up_tree234_init.c
up_tree234.m up_tree234_init.o
[nancy at woolloomooloo]$
So as you can see, c-files are there, trans-opt's are there, but it
takes three mmc-passes to get there? Three analyses? Can't I avoid this?
What options do I have to set? Perhaps MCFLAGS is not the suitable
make-variable to set?
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list