This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

compiling very large functions.


I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.

GCC has two competing interests here:  it needs to be able to provide
state of the art optimization for modest sized functions and it needs to
be able to properly process very large machine generated functions using
reasonable resources. 

I believe that the default behavior for the compiler should be that
certain non essential passes be skipped if a very large function is
encountered. 

There are two problems here:

1) defining the set of optimizations that need to be skipped.
2) defining the set of functions that trigger the special processing.


For (1) I would propose that three measures be made of each function. 
These measures should be made before inlining occurs. The three measures
are the number of variables, the number of statements, and the number of
basic blocks. 
Many of the gcc passes are non linear in one or more of these measures
and these passes should be skipped if one or more of these measures
exceeds some threshold.

For (2) I would propose that we add three new fields to the compilation
manager.  These fields would be null or zero if the optimization is
either essential or is only linear in the measure.  Otherwise, some
indication of either a threshold or the exponent of the growth is used
as the field. 

The compilation manager could then look at the options, in particular
the -O level and perhaps some new options to indicate that this is a
small machine or in the other extreme "optimize all functions come hell
or high water!!" and skip those passes which will cause performance
problems.

I do not claim to understand how sensitive every pass is to these
measures.  However, I could possibly make a good first cut on the rtl
passes. 

However, I think that before anyone starts hacking anything, we should
come to a consensus on an overall strategy and implement something
consistent for the entire compiler rather than attack some particular
pass in a manner that only gets us pass the next pr. 

Volunteer(s) to implement the compilation manager part of this would
also be appreciated.

Kenny



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]