From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19367 invoked by alias); 12 Dec 2007 20:54:42 -0000 Received: (qmail 19359 invoked by uid 22791); 12 Dec 2007 20:54:41 -0000 X-Spam-Check-By: sourceware.org Received: from wr-out-0506.google.com (HELO wr-out-0506.google.com) (64.233.184.231) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Dec 2007 20:54:30 +0000 Received: by wr-out-0506.google.com with SMTP id 60so155849wri.8 for ; Wed, 12 Dec 2007 12:54:27 -0800 (PST) Received: by 10.70.8.2 with SMTP id 2mr1812789wxh.69.1197492866836; Wed, 12 Dec 2007 12:54:26 -0800 (PST) Received: by 10.70.26.9 with HTTP; Wed, 12 Dec 2007 12:54:26 -0800 (PST) Message-ID: <998d0e4a0712121254q5e8d48dfxe9afc225e3f28b20@mail.gmail.com> Date: Wed, 12 Dec 2007 21:15:00 -0000 From: "J.C. Pizarro" To: "Diego Novillo" , gcc@gcc.gnu.org Subject: Re: [RFC] WHOPR - A whole program optimizer framework for GCC MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: 2007-12/txt/msg00387.txt.bz2 On 2007/12/12, "Diego Novillo" wrote: > Over the last few weeks we (Google) have been discussing ideas on how to > leverage the LTO work to implement a whole program optimizer that is > both fast and scalable. > > While we do not have everything thought out in detail, we think we have > enough to start doing some implementation work. I tried attaching the document, > but the mailing list rejected it. I've uploaded it to > http://airs.com/dnovillo/pub/whopr.pdf > > The most important goal we have with this project is the ability to > handle Really Large programs (millions of functions, millions of > call-graph edges) with some grace. So, the design tries pretty hard to > make use of concurrency and clusters to partition the work. > > At this point we are interested in getting feedback on the general idea. > There is some refactoring that will be needed inside the call-graph > manager and some aspects of the design may not even need a lot of > changes in GCC. But in general, it will require very efficient IR streaming. > > In terms of implementation, we will likely use the LTO branch as a > basis. Many of the features we will need are already being implemented > in the branch, so we will keep helping with that implementation. > > Thanks. Diego. * The googlish user says "i'm using the massive googlecc compiler that uses a lot of tons of libraries distributed in all the world!" * google shutdown => googlecc compiler doesn't work, ended history, byebye. J.C.Pizarro