Re: problems with the ipa pass manager.

[Jan Hubicka <hubicka at ucw dot cz>]

> The current design (or at least implementation) of the ipa pass manager 
> seems to have a serious design flaw.  The passes are called vertically 
> rather than horizontally.  What I mean by this is that
> 
> for each function F in the compilation unit
>    build the cfg for F
>   for each pass P in the ipa pass manager
>       call P (F);
> 
> This design has several serious flaws:
>   
> 1) The cfg is only built for the functions that have already been 
> processed.  They have not been built for the functions to be processed.

This is going to change with CFG inlining
> 
> 2) Many axillary functions have been booby-trapped to abort if the 
> function that they are called on does not have a cfg.
> consider
>   cgraph_function_body_availability calls
>   tree_inlinable_function_p calls
>   inlinable_function_p calls
>   inline_forbidden_p which has been booby-trapped. 
> 
> so with the current design, it is impossible ask important questions 
> about the functions that have not yet been processed.

These functions should in general work for function passed to the
analyze hook, but not for the functions being called from it since those
are not analyzed yet..
> 
> 3) With this current design it is impossible to implement a series of 
> ipa-based improvers since the output of one ipa is not seen by the 
> analysis routines of the next pass. 
> 
> Consider the case where it would be desirable to find and mark the set 
> of module level static which are readonly and do not have their address 
> taken and then using this analysis to do a better job of identifying 
> const and pure functions.  Unless you can do this in a single pass, you 
> are screwed by this ipa pass manager architecture.

Well, you should be able to collect the analysis at analysis time and
set the flags at execution time even if this is split in between passes.
> 
> 4) This ipa pass manager design will make it impossible to do true cfg 
> based inlining whose results can be seen by ipa passes since the actual 
> inlining, by design, must be done after all the ipa passes have finished 
> (this is the only time when the entire cfg has been built).
> 
> The proper design for this needs to be (where building the cfg is the 
> first ipa pass):
> for each pass manager pass P:
>  {
>     for each function F
>        call P.analyze_function(F)
> 
>     for each global variable V
>        call P analyze_variable (V)
>    
>     call P.execute()
> 
>     for each function F
>        call P.transform_function(F)
> 
>    for each global variable V
>        call P transform_variable (V)
>  }
> 

Hi,
we seem to hit again the problem on whether we want to do the analysis
first and modification later to allow real IPA later too that would
allow to do the analysis at compilation time.

I quite see that for the IPA passes development it is more convenient to
see them executed in the sequence, but I don't quite see how this can
scale up.  It seems to me that we perhaps want to go with combination of
these two approaches and have early compilation unit specific passes and
later the whole program passes, but even in this scenario the inlining
won't fit very well as we really want to have (most? of) inlining done
at whole program phase.

I would quite welcome some references here into how other production
compilers cope with this.  So far I was just looking into the SGI's
implementation and had dificulties to find anything usefull about the
others...

I can definitly move the analysis into separate loop so the cgraph and
basic flags are fully built before the analysis hooks are executed for
the current source level compilation unit, but I am still bit affraid to
go further to the requirement for everything to be readilly available
at each time.

Honza