This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
problems with the ipa pass manager.
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Jan Hubicka <jh at suse dot cz>, Steven Bosscher <stevenb at suse dot de>,Dale Johannesen <dalej at apple dot com>,Stuart Hastings <stuart at apple dot com>,GCC Mailing List <gcc at gcc dot gnu dot org>,"Berlin, Daniel" <dberlin at dberlin dot org>,"Novillo, Diego" <dnovillo at redhat dot com>
- Date: Fri, 19 Nov 2004 15:19:39 -0500
- Subject: problems with the ipa pass manager.
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.
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.
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.
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)
}