On Wed, Apr 14, 2010 at 5:57 PM, Diego Novillo <dnovi...@google.com> wrote: > 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.
Yeah, but that's all pie-in-the-sky stuff. We first have to really properly separate the frontends from middle-end - like solve the debug info issue with LTO. Like drive the whole compilation by the pass manager, not jump into/outof it all the time. But yes, moving the C frontend to a subdirectory was planned for a long time. I'm not sure about the rest - too much modularization can hurt as much as bring benefit. There is lots of generic infrastructure stuff that lurks around in tree-ssa-*.c optimizers (like all the fold_gimple stuff in tree-ssa-ccp.c that I long wanted to move to a gimple-fold.c ...). > 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. Well, maybe nice to have, but not really the theme of GCC, and not the most important cleanup areas. Unit-testing is a major missing feature, but at least for optimizers we could easily implement a poor-mans solution using the C frontend, -O0 and single enabled passes (given a slightly more clever pass manager). Richard. > >> 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. >
