From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1443 invoked by alias); 18 Dec 2007 13:29:21 -0000 Received: (qmail 1427 invoked by uid 22791); 18 Dec 2007 13:29:20 -0000 X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 13:29:16 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 4D0B9F031F; Tue, 18 Dec 2007 14:29:14 +0100 (CET) Date: Tue, 18 Dec 2007 13:48:00 -0000 From: Jan Hubicka To: Diego Novillo Cc: gcc@gcc.gnu.org Subject: Re: [RFC] WHOPR - A whole program optimizer framework for GCC Message-ID: <20071218132914.GB12527@atrey.karlin.mff.cuni.cz> References: <47603F3C.2090808@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47603F3C.2090808@google.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2007-12/txt/msg00519.txt.bz2 Hi, thanks for writting the proposal. It seems that at least in general terms we are all in sync. > 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. Doing call graph changes should not be that hard (I was trying to keep similar deisgn in mind when implementing it, even if we stepped away from the plan in some cases, like reorganizing passes from vertical to horisontal order). Nearest problem I see is merging different declarations of units read back, I have prototype implementation of DECL merging pass done from my trip this week and hope to have it working at least for --combine and C during christmas. Honza > > 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.