Re: [RFC] callgraph and unit at time compilation

[Daniel Berlin <dberlin at dberlin dot org>]

On 15 Nov 2002, Diego Novillo wrote:

> On Fri, 2002-11-15 at 20:53, Jan Hubicka wrote:
> 
> > My question is whether this approach looks sensible.  If so, I would
> > like to hear some comments from people more experienced with tree
> > inlining than I am.
> > 
> I would strongly encourage you to approach this problem in a
> language-independent manner.  In the future, we will want to do more
> than inlining.  We need to be able to build flowgraph for all/several
> functions in one compilation unit so that we can do inter-procedural
> analyses and optimizations.  We have some of the basic building blocks
> on the tree-ssa branch (there's even a call-graph builder).

The existing call-graph builder there isn't something i think should be 
reused, 
since it doesn't *build* a call graph, it just outputs one as it goes.

Also, the deferring of all functions is necessary to build a call graph, 
and has to be language dependent (since the deferring choice is made in 
the parser in some languages).
That part is not only sensible, I strongly support it.

 > 
> Solving this for only one front end will force us to solve the same
> problem for all the front ends.  Better design something that we can use
> in the future to do real unit-at-a-time optimizations.

If we want to do real unit-at-a-time optimizations, we need to write 
things out to disk (be it AST's or other information).  If we don't do 
this, it's just going to be either non-scalable, or non-workable.  If we 
aren't writing AST's due to whatever the heck politics, we are going to mainly 
stuck writing annotations and summaries (summaries of various flow 
info, side-effects, etc)
If Jan was to  work on this part of the infrastructure, which would 
consist of some sort of 
database, be it an  existing reuse of one, or something else, with an 
interface that let us  store annotations on things like trees, refs, and 
basic blocks, as well as storing some generic graph type with 
annotations on edges and vertices, it would make the rest of the basic 
unit-at-a-time infrastructure much easier to do right.
IMHO.
If we approach real unit-at-a-time optimizations from the perspective that 
we can keep everything in memory all the time, or redo everything all the 
time (rather than store some info somewhere on disk), we're just going to end up with 
something that is likely slow, huge (in memory footprint), unmaintainable, 
and non-scaling. 
We shouldn't build a house of cards when we have a chance to lay a real 
foundation.

 > > > Diego.
> 
>