From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11782 invoked by alias); 13 Dec 2007 07:39:36 -0000 Received: (qmail 11774 invoked by uid 22791); 13 Dec 2007 07:39:36 -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, 13 Dec 2007 07:39:32 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id lBD7dSpD022582 for ; Thu, 13 Dec 2007 07:39:28 GMT Received: from an-out-0708.google.com (andd40.prod.google.com [10.100.30.40]) by zps35.corp.google.com with ESMTP id lBD7dQUx028313 for ; Wed, 12 Dec 2007 23:39:27 -0800 Received: by an-out-0708.google.com with SMTP id d40so141952and.116 for ; Wed, 12 Dec 2007 23:39:26 -0800 (PST) Received: by 10.100.91.17 with SMTP id o17mr3461407anb.109.1197531566769; Wed, 12 Dec 2007 23:39:26 -0800 (PST) Received: by 10.35.119.5 with HTTP; Wed, 12 Dec 2007 23:39:26 -0800 (PST) Message-ID: <65dd6fd50712122339h2c856fdbpe127417e6726bd6@mail.gmail.com> Date: Thu, 13 Dec 2007 07:53:00 -0000 From: "Ollie Wild" To: tejgcc@westnet.com.au Subject: Re: [RFC] WHOPR - A whole program optimizer framework for GCC Cc: "Diego Novillo" , gcc@gcc.gnu.org In-Reply-To: <1197502096.6006.14.camel@tim-gcc> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47603F3C.2090808@google.com> <1197502096.6006.14.camel@tim-gcc> 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/msg00400.txt.bz2 On Dec 12, 2007 3:28 PM, Tim Josling wrote: > > Do you have any thoughts on how this approach would be able to use > profiling information, which is very a very powerful source of > information for producing good optimisations? The intent is for the WPA phase to utilize profile information, both for making transformation decisions and for assigning call-graph edge weights (which impacts partitioning and, hence, the local optimizations available during LTRANS). We've also discussed the possibility of bypassing LTRANS altogether for portions of the call-graph which profiling determines are insignificant. > A few years back there were various suggestions about having files > containing intermediate representations and this was criticised because > it could make it possible for people for subvert the GPL by connecting > to the optimisation phases via such an intermediate file. Arguably the > language front end is then a different program and not covered by the > GPL. It might be worth thinking about this aspect. The lto branch is already doing this, so presumably that discussion was resolved (Maybe someone in the know should pipe up.). This proposal aims to leverage (and augment) that work in progress. > This also triggers the thought that if you have this intermediate > representation, and it is somewhat robust to GCC patchlevels, you do not > actually need source code of proprietary libraries to optimize into > them. You only need the intermediate files, which may be easier to get > than source code. I believe a stable representation is an explicit non-goal of the LTO project (Perhaps that was the "resolution" of the discussion above.). It's an interesting idea, though. Maybe this is something to revisit once the representation has had a chance to stabilize. Ollie