On Wed, Apr 14, 2010 at 11:44, Nathan Froyd <froy...@codesourcery.com> wrote: > On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: >> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez >> <lopeziba...@gmail.com> wrote: >> > Otherwise, as Ian said in another topic [2]: "I have a different fear: >> > that gcc will become increasing irrelevant". >> >> That's my impression, as well. It is true of just about every code >> base, if it cannot attract new developers, it stagnates and eventually >> whithers away. >> >> To attract new developers, GCC needs to modernize its internal >> structure. I have some thoughts on that, but progress has been slow, >> due mostly to resource constraints. > > Would you mind expanding--even just a little bit--on what bits need > modernizing?
Sure, I commented on this a bit on the dragonegg thread (things we'd like to borrow from LLVM). In general, I would like to continue the separation of the various modules in the pipeline. In particular: - Firm APIs: remove global state, add public interfaces. - Split up the gcc/ directory. Move major components into libraries (e.g, libgimple, librtl, libgeneric). - Make each library a standalone module, with separate testsuites. - Add unit tests for each library. - Make all the major IRs streamable so that do things like remove the current gty-based pch generation, or allow testing of individual passes. - Remove the macro-based back end configuration. Convert it to registered callbacks. Allow backends to be compiled into a separate library that can be loaded at runtime. The theme is modularization at the library level so that we can build/test these components separately. The driver could simply be dynamically linked to all of them. > http://gcc.gnu.org/wiki/Speedup_areas > > and perhaps: > > http://gcc.gnu.org/wiki/general_backend_cleanup Those too, yes. > I know there are ugly parts still remaining in GCC. But my experience > (extending/parameterizing an LLVM optimization pass, writing/modifying > GCC middle-end optimization passes, some GCC backend hacking) suggests > that the complexity is similar. I think concrete "I tried X and it > sucked" or "these are the areas of suckage" would be helpful. My ulterior motive for all this modularization is to extend Tom Tromey's incremental compiler. But I also think that it has other benefits, mostly in testing and maintenance. I've been collecting thoughts in this area for a few weeks. I will try to get it finished and publish it on the wiki. Hopefully, soon. Diego.
