> 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. >
If profiling data is available at the point of decision, may want to take into account also how hot is the function (have the threshold depend on the size of the function vs. its expected impact on performance based on profiling) dorit > 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 > >
