Re: *ping* [PATCH] unit-at-a-time for java

[Jan Hubicka <hubicka at ucw dot cz>]

> On Thu, 4 Sep 2003, Jan Hubicka wrote:
> > > On Wed, 3 Sep 2003, Jan Hubicka wrote:
> > > > Hmm just curious, what happens to the functions that gets inlined
> > > > completely so they are never expanded then?
> > >
> > > That never happens in Java.  Every function is referenced from the method
> > > table, so has TREE_ADDRESSABLE set, etc.  (It's one of the reasons the
> > > executables are so huge.)
> >
> > I see, so without some kind of global optimizations one can not remove a
> > function body....
> 
> Global optimizations for Java are a bit tricky, since it is so common to
> bind to symbols at runtime.  Consider the bytecode interpreter.
> 
> Regardless, it would be useful to have a flag that tells the compiler
> "nothing in this translation unit besides main() will ever be referenced
> from outside, statically or at runtime" so that dead functions can be
> easily identified and stripped away.  I can imagine embedded
> developers wanting such a feature.

I am thinking about implementing this for C.  With our intermodule
support with can have flag -fwhole-program that will effectively turn
all public symbols into static symbols (with proper binding across C
modules that is not problem) except for symbol main and possibly other
that are marked by attribute (I guess "used" attribute can be used for
this kind of semantic).

The resulting programs should be considerably smaller and faster (at
least on i386 we will use register passing conventions then and we will
do better inlining decisions for instance), but I am having problems how
to realize it in our tree representation.

Rewriting the TREE_PUBLIC flag in tree representations once whole unit
is parsed looks somewhat kludgy as it has perfect semantics for
frontend, so I guess we should add new predicates with backend semantics
then.  I already have notion of local functions so use something like
that.
> 
> > I was thinking a bit that in such a case it would be possible to find a
> > postorder that allows you to satisfy all the inlining decisions.
> > Basically if you postorder only the subgraph created by inline edges you
> > will get it as it is always acyclic.
> 
> Is the complete graph of inline edges always acyclic?  Is it not
> possible for two methods to inline each other's bodies?

Yes, that is the current property of graph.
If we would allow such kind of inlining, we would need to extend the
datastructure in a way that we will insert new node representing cloned
function body when we decide to inline some call.  That way we can do
recursive inlining and so on, but our current tree inliner is not able
to deal with this (as while expanding the first method it will inline the
second and while expanding the second it has no orignal copy of the
first).
I plan to allow at least some kind of recursive inlining (inlining
enough times to make function body large), but this requires adding code
to clone original body and it would be nice to know about tail calls as
these should not be expanded this way we don't know without tree-SSA
yet.  So I am going to play with this on tree-ssa branch.
> 
> It may have made things a little easier for Java at the moment, though as
> I mentioned earlier the reverse inlining situation is quite rare.  It
> happened once while compiling all of libjava.
> 
> > Definitly we can get it by doing embedded dfs over the inline edges each
> > time we get into the new node....
> 
> Sorry, what is "dfs"?
Depth first search.  Once you get to method A, you currently follow to all
it callees.  Instead we can follow into all calees reachable by inline
edges first and stack the non-inline edges for later getting these
resolved with priority.

Honza
> 
> Jeff