On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote: > On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: >> 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. > > Why before inlining? These three numbers can change quite significantly > as a function passes through the pass pipeline. So we should try to keep > them up-to-date to have an accurate measurement. > I am flexible here. We may want inlining to be able to update the numbers. However, I think that we should drive the inlining agression based on these numbers.
Well, for example jump threading and tail duplication can cause these numbers to significantly change. Also CFG instrumentation and PRE can increase the BB count. So we need to deal with cases where an optimization produces overly large number of basic blocks or instructions. (like by throtting those passes properly) Richard.
