From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12138 invoked by alias); 5 Jun 2008 15:23:56 -0000 Received: (qmail 12067 invoked by uid 22791); 5 Jun 2008 15:23:55 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 15:23:38 +0000 Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id m55FM11W006510 for ; Thu, 5 Jun 2008 16:22:01 +0100 Received: from ti-out-0910.google.com (tidj3.prod.google.com [10.110.136.3]) by spaceape11.eur.corp.google.com with ESMTP id m55FLxQ8031276 for ; Thu, 5 Jun 2008 16:22:00 +0100 Received: by ti-out-0910.google.com with SMTP id j3so194751tid.8 for ; Thu, 05 Jun 2008 08:21:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.144.9 with SMTP id r9mr1975167ybd.41.1212679317924; Thu, 05 Jun 2008 08:21:57 -0700 (PDT) In-Reply-To: <20080605150941.GA24241@atrey.karlin.mff.cuni.cz> References: <96A87E23-CD76-41E3-A4BD-DD399C847F17@apple.com> <4846B475.8030907@naturalbridge.com> <8AA7CF45-8855-49EE-A4FD-5C4441639203@apple.com> <65dd6fd50806041223l1871ecfbh384aa175c3da0645@mail.gmail.com> <4846F50A.5050900@naturalbridge.com> <20080605150941.GA24241@atrey.karlin.mff.cuni.cz> Date: Thu, 05 Jun 2008 15:23:00 -0000 Message-ID: Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA From: Diego Novillo To: Jan Hubicka Cc: Kenneth Zadeck , Ollie Wild , Chris Lattner , gcc@gcc.gnu.org, Jan Hubicka , Rafael Espindola , Robert Hundt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2008-06/txt/msg00115.txt.bz2 On Thu, Jun 5, 2008 at 11:09, Jan Hubicka wrote: > I think one problem is that both repackaging and cherry picking as > described is very centric about application on inlining. No, that's simply the main application for the initial implementation. Any other summary-based transformation can be supported the same way. Optimizations that are not summary-based can be done the way they're done today. All that happens is that they won't be able take advantage of the partitioning and distribution since WPA and LTRANS will be executed together. And of course, even summary-based transformations can be done the same way they are done today. The scaling aspects of WHOPR should only kick in via a special option, or even via heuristics. > I personally always leaned to kind of repackaging scheme. I've hoped > that with sanely designed LTO dumping scheme, this will be relatively > straighforward to implement: simply you re-use same serialized functions > as they are in the original .o files and replace function summaries by > transformation summaries, so we might pretty much re-use same > infrastructure. With sane caching mechanizm to keeping unmodified > function bodies in memory in cooperation in GGC, the repackaging stage > should be possible to implement as simple pass through the callgraph > writting the selected functions to the output file. Sure. All this is possible and we shouldn't break it. Diego.