implementing escape analysis

[David Daney]

Andrew Haley wrote:
> Diego Novillo writes:
>  > Andrew Haley wrote:
>  > 
>  > > http://www.research.ibm.com/people/g/gupta/escape.ps
>  > > 
>  > > But I probably wouldn't recommend you to do it in a gcj-specific way.
>  > > gcj is merely the Java language front-end for gcc, and there may be a
>  > > plan for escape analysis that will suit all gcc's languages that can
>  > > use it.
>  > > 
>  > Oh, excellent.  It's been in my wish list for a while.  I agree with
>  > Andrew, this analysis should not be done in the individual front ends.
>  > At worst, I could envision langhooks if we needed to get some
>  > FE-specific information.
>  > 
>  > Choi's paper is a good start.  I remember it being quite reasonable, but
>  > I am not aware of recent results in the literature.  We already have
>  > some primitive (well, embarrassing) support for determining escape
>  > points.  See tree-ssa-alias.c:is_escape_site.
> 
> I remember the weird thing about that paper (it's been a long time
> since I read it) is that it didn't talk much about inheritance.  It
> seems to me that inheritance is one of the greatest problems for an
> object-oriented language...
> 
>  > Essentially, a good escape analysis technique should probably be
>  > incorporated at that point.  I have not yet thought about the details,
>  > but I'd be happy to help with the implementation.
> 
> In theory it doesn't look all that difficult do do in the simple
> cases, but a good implementation would need a lot of knowledge about
> the way the class library behaves, and therefore what might escape.  A
> database, I suppose.  But just a skeleton implementation that does a
> few simple things would be nice.
> 

Is is possible to do a conversion of a heap allocation to a stack 
allocation in a language independent manner in GCC?

I keep threatening to do this for gcj, but was thinking that the best 
place to do it may be the front end.  Once in tree-ssa form it is more 
difficult to figure out that a call to _Jv_AllocObject followed by a 
call to the constructor is the equivalent of the 'new' operator.

Also replacing calls to a general purpose type 
(StringBuilder/StringBuffer) to an optimized version 
(gnu.gcj.runtime.StringBuffer) requires very large changes to the 
tree-ssa form, but in the front-end it is quite simple.

The ability to do a good job of both of these transformations has to be 
based on (at least a simplified form of) escape analysis of the runtime 
library.

David Daney