[m-rev.] for review: inter-module analysis framework

[Nancy Mazur]

* Simon Taylor <stayl at cs.mu.OZ.AU> [2002-08-09 15:17]:
> On 09-Aug-2002, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> > * Simon Taylor <stayl at cs.mu.OZ.AU> [2002-08-09 13:56]:
> > > I still don't understand why an analysis pass cares which variables
> > > were present in the original program. If you are reading terms
> > > containing variables from a file, and trying to match them against
> > > terms computed during the current compilation, you will always
> > > have to deal with renaming.
> > 
> > I don't mind the renaming, it'll always be needed of course, but I just
> > need to know which variables correspond to the actual headvariables... 
> > 
> > Just for the small example of append... dumping out the hlds at stage 48
> > or whatever gives something like: 
> > append:app(TypeInfo_for_T, HeadVar__1, HeadVar__2, HeadVar__3):- 
> > with a type-info variable artificially added to it... 
> > but of course, in the analysis results, I don't care about TypeInfo's,
> > even worse, I don't want them... I don't care whether the headvars are
> > listed as [HeadVar__1, ..] or [A,B,C]... 
> 
> You haven't explained why you don't want the type-infos.
> Type-infos can be heap allocated, so it makes sense to try to
> optimize them using structure reuse, as in the following example:
> 
> :- pred write2(T::in, U::in, io__state::di, io__state::uo) is det.
> write2(T, U) -->
> 	io__write([T]),
> 	io__write([U]).
> 
> Polymorphism will transform this into:
> 
> write2(TypeInfo_For_T, TypeInfo_For_U, T, U) -->
> 	{ TypeInfo_For_List_T = type_info_for_list(TypeInfo_For_T) },
> 	io__write(TypeInfo_For_List_T, T),
> 	{ TypeInfo_For_List_U = type_info_for_list(TypeInfo_For_U) },
> 	io__write(TypeInfo_For_List_U, U).
> 
> The construction of TypeInfo_For_List_U should be able to reuse
> the cell allocated for TypeInfo_For_List_T if the analysis can
> prove that `io__write' does not alias TypeInfo_For_List_T.

Yes, they may be interesting for structure reuse, but they do not belong
in the interface-information about the predicate.

The problem is elsewhere, and I'll try to illustrate it with the
following: 

- append. As said earlier, a type-info headvar is added to it... so
evaluating proc_info_headvars/2 in the case of append gives me a list
of 4 variables. A priori, I don't know which of them are the actual
headvars, and which one of them is the artificial added one? Is it the
first? The last? I might filter them out by removing the type-info's
explicitly, but then what about those exceptional cases where the
predicate _is_ explicitly defined with type_info's (like in std_util
somewhere), or what if new additional artificial variables are
introduced? 
- okay, so I don't filter it out, and I have to work with those 4
variables. No problem, I dump my CTGC-information by listing those
4 variables first, and then the actual success-pattern... 
- note that the interface file of the module in which append is defined
declares a predicate with arity 3. 
- and now comes the problem-part. When compiling a module, say 
"use_append", which imports the module where append is defined, then 
the corresponding pred_info's en proc_info's are created for append
(with empty body of course), but with only 3 headvars... at this stage
the analysis file of append is read, but there my information is in
terms of 4 headvars! which ones do I have to match with? because in
order to be correct, my CTGC-information needs to be renamed to those 3
headvars.. 

At this moment the type-info's are artificially removed, but I don't
like this solution. In an earlier stage I duplicated the field for 
the headvars in proc_info "before" additional headvars where being
created, but now something else is being done with these headvars (and I
suppose the link you've given me here will give me the solution), so 
that suddenly didn't work as supposed... 

As I said, I'll have to take a closer look into that again... 

> > But now that we're talking about renamings, some time ago I remember
> > somebody (Zoltan?, Mark?) added a change so that during debugging the
> > original names used by the programmer in the program are used instead
> > of these awkward HeadVar__1, etc... 
> > Can somebody point me to those changes, because the online search
> > facilities are quite limited... 
> 
> http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-reviews/mercury-reviews.0206/0027.html

Okay thanks! that was what I was looking for.. 


And now a totally different consideration. With your remark of simply
putting my list of headvars in the call-pattern, I started to wonder why
you make the distinction between call and success pattern in the
analysis results. A priori the call and success pattern is simply some
part of the analysis result of some predicate. Also, analyses may
produce information that is call pattern independent? 

So somehow I would tend to have an interface like: 

analysis_type(func_id, analysis_result)

and then have some additional machinery if analysis_result matches with 
a type (call_pattern, success_pattern)... 

just my 2cents, 
Nancy
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------