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.
