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

[Simon Taylor]

On 09-Aug-2002, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> > 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:

...

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

For passes which run after polymorphism the type-infos are part of the
interface of 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.. 

So you can't do anything with the analysis information until
after polymorphism has been run. Where's the problem?
 
> 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... 

This is why trying to treat the "original" variables as a special
case is a bad idea. The compiler makes no distinction between
original and introduced variables, so minor changes will break
any code which attempts to make the distinction.

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