Eric Botcazou <[EMAIL PROTECTED]> writes: > > Please, just look at those charts > > > > https://vmakarov.108.redhat.com/nonav/spec/comparison.html > > > > The compilation speed decrease without a performance improving (at least > > for the default case) is really scary. > > Right, I also found those charts a bit depressing, given the time and energy > that have been put in the compiler since GCC 3.2.3. For example, it seems > that the Tree-SSA infrastructure has brought very little benefit in terms of > performance in the generic case, in exchange for a massive dump of new code. > > Does anyone have the beginning of an idea as to why this is so? Did GCC hit > a > fundamental wall some time ago, for example because of its portability? > > On the other hand, those efforts have not been lost, since the compiler is > now > much more modern in terms of infrastructure and algorithms. However, before > triggering the next internal earthquake (namely LTO), we should probably try > to understand what's going on (or not going on).
These charts are certainly discouraging. On the other hand, for some real code we're seeing each new version of gcc produce an incremental runtime improvement. So I'm not sure what to make of it. This is hardly a new thought, but I believe that for the i386 gcc is handicapped by reload. No matter how smart we are before reload, it just take one poor decision by reload in an inner loop and we've lost all the gains. Reload has enormous complexities which are mostly irrelevant for the i386. And I think that the idea of doing register allocation separately from spill code generation does not make sense on the i386. I don't think gcc has hit any sort of wall, except insofar as we have no plan for eliminating reload. I don't think portability comes into play here. That said, I certainly agree that we should try to figure out what is going on as much as possible. I also want to say that at present LTO is a collection of different projects. Most of them are aimed directly at speeding up the compiler, reducing compile time. So far nobody is working on any changes to the actual optimization framework. So I'm not too concerned yet about LTO in this context. I certainly agree that when LTO moves into an optimization phase, we need to make sure that any default passes pay off in terms of compilation time or runtime performance. Ian
