problems with the ipa pass manager.

[Jan Hubicka]

> > There is certainly the question of scaling.  There always is and there 
> > always will be.  I have not and would not advocate using the same 
> > algorithms at the module level as I would with the full program in front 
> > of me.  As the context gets larger the algorithms applied in that 
> > context must get weaker and weaker, or else the compilation will never 
> > finish.  However, for the level of a single compilation unit, it is not 
> > only possible but completely practical to use the same techniques that 
> > one uses on the for a single function. 
> > 
> > It was my understanding, that for the whole program compilation that 
> > when we compile each file to produce the .o file, we do a fairly good 
> > job of transforming that module before writing out the il and only do 
> > simple things that depend on the whole program at link time.  From that 
> > point of view, I believe that the plan is to output the ssa level il, 
> > and it is my plan to have done a significant amount of processing on 
> > that.  Given that a substantial number of calls in a c program are 
> > local, we should be able to extract a fair number of benefits early.

I was thinking about this a bit more.  How much of algorithms for IPA
optimizations you would expect to exist in two versions (for single unit
and for whole program)?  It seems to me that most of the major IPA
transformations are fairly scalable and I don't know about any
implementation that would use more powerfull algorithms for single unit
first followed by traditional link time IPA.

It also seems to me that we don't want the compiler to be too much
dependent on the compilation unit choice as this is pretty much
artifical and depends on programming style...

But, of course, for some cases it makes sense to have unit scale
specific optimizers, just I wonder how much of the stuff will need to be
redesigned when (if) we get into link time IPA busyness.

Honza