[m-dev.] for review: `possible' alias analysis stage

[Nancy Mazur]

Hi,
sorry for this delay in my reply... 

> > Added `possible' alias analysis stage (before unique modes analysis).
> 
> What's the rationale for this change?

Okay, here goes. 
The `possible' alias analysis stage is one step of three in the 
process of deriving liveness information. And liveness information
itself is essential for a structure-reuse analysis which decides
whether some datastructures can be reused or not (depending
on the call pattern of the procedures). The reason why `possible'
aliasing is needed in this process can be illustrated as follows: 

	:- pred p(list(T)::in, list(T)::out, list(T)::out) is det.
	p( X, Y, Z ) :-
		q( X, Y ),  	     % - (Y might be aliased with X)
		(  X = [ Xe | Xs ]   % - does the top-level list-cel
				     % become available for reuse? 
				     % You can't be sure about that, due
				     % to the fact that Y might point to 
				     % this cel
		-> Z = [ Xe ]        % - so reuse here won't be allowed
		;  Z = [] ). 
		
Is this a rationale enough? Or should it be explained more 
thoroughly? 

Oh, and the reason why I've put this stage just before the unique
mode analysis pass, is that, after discussing with David about it, 
we've come to the conclusion that this information about possible
aliasing might be useful for that stage too, the rationale behind
it being similar to the above explanation...

> One of the reasons why it is important to explain the rationale
> is that often things change.  If, for example, possible alias
> analysis was added to support HAL, and then later it turned out
> that HAL didn't need possible alias analysis after all, 
> we might want to remove the possible alias analysis stuff.
> But if the log message doesn't say why it was added, then
> we will have a hard time figuring out whether it will be
> OK to remove it.

okay. 
so in this case,  
possible aliasing <= (part of) liveness analysis <= reuse analysis
                  <= unique mode analysis (?)

> > compiler/handle_options.m
> > compiler/hlds_out.m 
> > 	added option/handler to print alias information in hlds_dumps
> > 	(`kulalias' or `k')
> 
> To ensure that these log messages are easily machine-parsable,
> please ensure that you stick exactly to the format used by
> other log messages.  In particular:
> 
> 	- "estimated hours taken:" should start with
> 	  a capital "E".
> 
> 	- after each file name, there should be a colon (":").
> 
> Also, it's nice if the log messages are properly punctuated
> (e.g. starting with a capital letter and ending with a full stop).

I'll try to stick to these rules. 

> > compiler/prog_data.m
> > compiler/prog_io_pragma.m
> > compiler/module_qual.m
> > compiler/modules.m
> > compiler/mercury_to_mercury.m
> > compiler/make_hlds.m
> > 	added new prog_data__pragma_type constructor: ka_alias_info/5
> > 	added new pragma-declaration: ka_alias_info/3
> > 		:- pragma ka_alias_info( <small pred declaration>,
> > 			vars( <list of headvars> ), 
> > 			maybe( <printed alias-information> ) ).
> > 		This pragma-declaration is not intended to be 
> > 		used directly by the programmer.
> 
> I don't think using the abbreviation `ka' (for "KUL alias")
> here is a good idea.  Likewise for the filenames ka_*.m
> and for the file extension `.ka'.
> I think it would be better to use an abbreviation that gives
> information about what the declaration or file is for, rather
> than about where it was developed.  For example, you could
> use `pa' (for "possible alias").

The reason why I used ka (KUL alias) was not so much to 
point to the place where it was developed, but rather to clearly distinguish
our different definitions of aliasing (the mercury compiler usually
used definite aliasing).. but pa is good for me.. 

> > new files:  (ka = KUL-alias)
> > compiler/ka_alias_as.m  : definition of the abstract substitution and
> > 			 it's primitive operations
> > compiler/ka_run.m : main module for effectively running the analysis pass
> > compiler/ka_util.m : some extra types/procedures, mainly definition of
> > 		a fixpoint table.
> 
> To ensure that these log messages are easily machine-parsable,
> please ensure that you stick exactly to the format used by
> other log messages:
> 
> 	<directory/file>:
> 		<detailed description of changes>
> 
> Note that the detailed description starts on a new line,
> and is indented by just one tab.

ok

> It's best not to use "new files:", since that might be misinterpreted
> (by software parsing the log messages) as a file name.  Instead, for the
> new files you can insert "New file." at the start of the <detailed
> description of changes> for each such file.

didn't know that, but ok

> > Index: handle_options.m
> > ===================================================================
> > RCS file: /home/mercury1/repository/mercury/compiler/handle_options.m,v
> > retrieving revision 1.88
> > diff -u -r1.88 handle_options.m
> > --- handle_options.m	2000/01/10 05:26:18	1.88
> > +++ handle_options.m	2000/02/08 00:15:19
> > @@ -854,9 +854,11 @@
> >  :- pred convert_dump_alias(string, string).
> >  :- mode convert_dump_alias(in, out) is semidet.
> >  
> > -convert_dump_alias("ALL", "abcdfgilmnprstuvCIMPTU").
> > -convert_dump_alias("all", "abcdfgilmnprstuvCMPT").
> > +convert_dump_alias("ALL", "abcdfgiklmnprstuvCIMPTU").
> > +convert_dump_alias("all", "abcdfgiklmnprstuvCMPT").
> >  convert_dump_alias("codegen", "dfnprsu").
> >  convert_dump_alias("vanessa", "ltuCIU").
> >  convert_dump_alias("paths", "cP").
> >  convert_dump_alias("petdr", "din").
> > +convert_dump_alias("kulalias", "k").
> 
> Continuing with my earlier suggestion about naming things
> for what they are rather than where they were developed,
> it would probably be better to use "A" for "possible alias"
> information (unfortunately both p and P are already taken)
> rather than "k".
> 
> [... to be continued ...]

ok


once again, sorry for the delay in my reply... 
Nancy

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