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

[Nancy Mazur]

Hi,

> > In attachment I've included a file that Mission Critical once gave us, 
> > and for which explicit di/uo annotations are written, but for which
> > our liveness analysis can automatically derive them. That wouldn't
> > have been possible with the alias branch (as the alias branch 
> > needs those di/uo's), and wouldn't have been possible without 
> > possible aliasing information. 
> 
> The current Mercury compiler is quite capable of inferring those
> di/uo's in many cases, including the example that you gave.  Indeed,
> I'm pretty sure that the mode declarations in that example were originally
> copied from the output of the Mercury compiler!  They look suspiciously
> similar to the modes that the compiler infers, which tend to be a bit
> different to the modes that a human would write by hand.

*blush* okay.. got me on that one.. didn't know it... 
but anyway, this does not change the discussion...

> > Definite aliasing is (in the liveness analysis context) definitely 
> > not enough for deciding whether some structures may be reused or not. 
> > While there might be no definitie alias between some variable X and
> > some variable Y, you cannot safely decide that one of those may be
> > reused at some point. Only if you're sure that there will never ever
> > be an alias between those two, you can safely make the decision. In
> > order to know this 'never ever', possible aliasing information is
> > needed.
> 
> That's true.  But the Mercury compiler's "uniqueness" analysis
> does keep track of some degree of possible aliasing /
> definite not aliasing:
> 
> 	if a variable has inst `unique', it means that that
> 	variable definitely does not alias with anything
> 	(i.e. the possible alias set is empty)
> 
> 	if a variable has inst `ground', it means that that
> 	variable might alias with anything
> 	(i.e. the possible alias set is the universal set)
> 
> If you're proposing that we do a more sophisticated analysis of possible
> aliasing, I would like to know what benefit we will get from the
> additional complication.

In some sense I would like to know it too, this is what my research is
all about. In another sense, I do strongly believe that a consolidated
theoretical basis for structure reuse detection is a good start. 
For practicality, some simplifications will have to be made at some
point. But this seems too early to me. 

We have run quite some experiments with our prototype implementation
of the whole (liveness), and quite some opportunities of reuse are detected
(within library modules, a couple of compiler-modules) of which I'm not
sure the current compiler would be able to detect them (reuse within
for example tree234__insert/4 and others, but perhaps I'm wrong, and the 
current compiler safely does the job?). 

Anyway, I can understand that at this moment it might seem early to
include possible aliasing (+ the whole reuse-stuff) in the mainstream 
compiler, it's okay for me if you'd prefer it to be restricted to 
a separate branch.

Again, sorry for my late reply, had a lot of other stuff to do first..

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