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.