From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11324 invoked by alias); 14 Apr 2010 14:34:52 -0000 Received: (qmail 11307 invoked by uid 22791); 14 Apr 2010 14:34:50 -0000 X-SWARE-Spam-Status: No, hits=4.7 required=5.0 tests=BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45,TBC,TW_LV X-Spam-Check-By: sourceware.org Received: from mail-qy0-f193.google.com (HELO mail-qy0-f193.google.com) (209.85.221.193) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Apr 2010 14:34:45 +0000 Received: by qyk31 with SMTP id 31so221019qyk.20 for ; Wed, 14 Apr 2010 07:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.37.137 with HTTP; Wed, 14 Apr 2010 07:34:43 -0700 (PDT) In-Reply-To: <003b01cadbde$21913eb0$64b3bc10$@com> References: <003b01cadbde$21913eb0$64b3bc10$@com> Date: Wed, 14 Apr 2010 14:58:00 -0000 Received: by 10.224.72.136 with SMTP id m8mr407271qaj.223.1271255683272; Wed, 14 Apr 2010 07:34:43 -0700 (PDT) Message-ID: Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) From: Steven Bosscher To: Grigori Fursin Cc: Dorit Nuzman , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00335.txt.bz2 Hi, You know, I'm getting pretty fed up with all this LLVM advocacy on a GCC list. It's distracting and counter-productive. It is not as if anything mentioned in this feedback is new and not already known here on the GCC list. Repeating the long list of known problems won't help GCC. Can we now please return to discussions about GCC here? Please? Ciao! Steven On Wed, Apr 14, 2010 at 4:23 PM, Grigori Fursin wrote: > Hi all, > > Dorit and I just got an anonymous ;) feedback about GCC vs LLVM following > our email about GROW'10 panel questions so we are just forwarding it here > (non-edited): > > The reasons I have seen for using llvm/clang are basically two-fold: gcc = is too slow and too > complicated. (This is true even for a company with significant in-house g= cc expertise.) The C > language parser for llvm (clang) is far faster than the gcc equivalent, e= asier to modify, and easier > to build into a separate library. Speed is a major decision for choosing = clang/llvm, as OpenCL needs > to be complied on the fly. The llvm infrastructure is also far easier to = manipulate and modify than > gcc. This is particularly important as implementing OpenCL means building= complier backends to > generate Nvidia's PTX or AMD's IL, adding specific vector extensions, and= supporting various > language intrinsics. I don't know how much of an issue the licensing issu= es may be. These issues, > plus significant corporate backing, appear to be really driving llvm in t= he OpenCL area. My > impression is that for gcc to be competitive it will have to offer both c= omparable compilation speed > and dramatically better code optimizations. Even then, I'm not sure if th= e difficulty of working > with it will be considered a good tradeoff for most companies. > > Cheers, > Grigori > > > -----Original Message----- > From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of D= orit Nuzman > Sent: Sunday, April 11, 2010 2:54 PM > To: gcc@gcc.gnu.org > Subject: Notes from the GROW'10 workshop panel (GCC research opportunitie= s workshop) > > > Dear all, > > We would like to share notes from the lively panel discussion at > GROW'10 (GCC Research Opportunities Workshop) that took place at the > end of January in Pisa, Italy (alongside the HiPEAC conference). > The main topic of the discussion was: > > =A0 =A0 =A0How to make GCC more attractive to researchers, > =A0 =A0 =A0and how GCC can benefit from researchers? > > Here is the list of major points and wishes raised by participants: > > * Need to encourage cleanup/infrastructure work on GCC and provide > stable/flexible/extensible APIs (the question is how to encourage such > infrastructure work...?) > > * Encourage people to work on infrastructure and full implementation > that actually works: Lobby for high quality conferences to reserve a quota > of the accepted papers to papers that focus on *implementation* work (and > start with HiPEAC!) > > * Follow up to the above: Encourage research that actually works: > Lobby for conferences to favor research work that is tested on a realistic > environment (e.g. pass all of SPECcpu...), and that is reproducible. > Then GCC and the community could immediately benefit from the results and > not wait for many years before someone decides to reproduce/redo research > ideas in GCC. > > * Get statistics on percentage of papers/projects that use compilers other > than GCC, and ask them why... (By the way, why was OpenCL implemented only > on LLVM and not on GCC?) > > * Open up GCC to be used as a library by other tools, so that other tools > could use its analysis facilities. For example, having alias analysis as = an > API rather than a pass that needs to be applied and then collect > information. Allow developers/tools access those functions outside GCC > (should be a high-level API). > > * Follow up to the above: Need to come up with a common API / > standardization / common levels of abstractions. Decide on how to > coordinate efforts and find commonalities. > > * Need a simple pass manager that can list all available passes > and allow any scheduling (providing dependency information). > > * Make more visible/accessible guides for building/extending GCC. > > * Better advertize Google Summer of Code, and provide more mentoring. > > * Send feedback on which plugin events are desired to add to next releases > of GCC. > > * GCC tries to auto-parallelize the programs it compiles. Will GCC itself > be made more multi-threaded and run faster in a multi-core environment...? > > > We've collected these and other comments/suggestions before/at/after the > workshop, on the GROW'10 wiki page: > http://cTuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Panel_Qu= estions > > > > We hope these notes would help improve GCC and its appeal/usability for > researches (or at least raise more discussion!) > > Yours, > Grigori Fursin and Dorit Nuzman > (GROW'10 organizers) > >