From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18224 invoked by alias); 14 Apr 2010 16:06:18 -0000 Received: (qmail 18209 invoked by uid 22791); 14 Apr 2010 16:06:16 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,SARE_MSGID_LONG45 X-Spam-Check-By: sourceware.org Received: from mail-gw0-f47.google.com (HELO mail-gw0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Apr 2010 16:06:11 +0000 Received: by gwaa20 with SMTP id a20so115696gwa.20 for ; Wed, 14 Apr 2010 09:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.79.14 with HTTP; Wed, 14 Apr 2010 09:06:09 -0700 (PDT) In-Reply-To: References: <003b01cadbde$21913eb0$64b3bc10$@com> <20100414154431.GR540@codesourcery.com> Date: Wed, 14 Apr 2010 18:30:00 -0000 Received: by 10.150.247.3 with SMTP id u3mr7346867ybh.41.1271261170028; Wed, 14 Apr 2010 09:06:10 -0700 (PDT) Message-ID: Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) From: Richard Guenther To: Diego Novillo Cc: Nathan Froyd , =?ISO-8859-1?Q?Manuel_L=F3pez=2DIb=E1=F1ez?= , Steven Bosscher , Grigori Fursin , Dorit Nuzman , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00344.txt.bz2 On Wed, Apr 14, 2010 at 5:57 PM, Diego Novillo wrote: > On Wed, Apr 14, 2010 at 11:44, Nathan Froyd wr= ote: >> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: >>> On Wed, Apr 14, 2010 at 11:18, Manuel L=F3pez-Ib=E1=F1ez >>> 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. =A0It 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. =A0I 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. =A0In particular: > > - Firm APIs: remove global state, add public interfaces. > - Split up the gcc/ directory. =A0Move 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. =A0Convert it to > registered callbacks. =A0Allow 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. =A0The 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. =A0But 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. =A0I 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. =A0But 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. =A0I will > try to get it finished and publish it on the wiki. =A0Hopefully, soon. > > > Diego. >