Re: compiling very large functions.

[Andrew Haley <aph at redhat dot com>]

Kenneth Zadeck writes:
 > Paolo Bonzini wrote:
 > >
 > >> While I agree with you, I think that there are so many things we
 > >> are already trying to address, that this one can wait.  I think
 > >> we've been doing a very good job on large functions too, and I
 > >> believe that authors of very large functions are just getting
 > >> not only what they deserve, but actually what the expect: large
 > >> compile times (superlinear).
 > >
 > > Not too mention, that these huge functions are usually central to
 > > the program.  If GCC decided that it is not worth optimizing the
 > > machine-generated bytecode interpreter of GNU Smalltalk, for
 > > example, I might as well rewrite it in assembly (or as a JIT
 > > compiler).  Same for interpret.cc in libjava, though it is a tad
 > > smaller than GNU Smalltalk's interpreter.
 > >
 > > Unlike the authors of other VM's, I have no problem writing code
 > > so that the *latest* version of GCC will do its best, instead of
 > > complaining that GCC compiles my code worse on every release.
 > > So, I am ok with GCC doing stupid things because of bugs that
 > > I/we can fix, but not with GCC just giving up optimization on
 > > code that has always been compiled perfectly (in one/two minutes
 > > for about 30,000 lines of machine-generated code, despite being
 > > chock-full of computed gotos), that *can* be optimized very well,
 > > and that is central to the performance of a program.

 > I actually think that you small talk example is the exception and
 > not the rule.

Mmm, probably.  But these interpreters, while uncommon, are important
in the sense that they are executed a great deal.  Paolo is surely
right: we don't want to cease to optimize those important programs on
which we've done a good job in the past.

 > The thing is that even as memories get larger, something has to
 > give.  There are and will always be programs that are too large for
 > the most aggressive techniques and my proposal is simply a way to
 > gracefully shed the most expensive techniques as the programs get
 > very large.

Indeed, yes.

 > The alternative is to just to just shelve these bugs and tell the
 > submitter not to use optimization on them.

It's hard to argue with your reasoning.

Andrew.