From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21800 invoked by alias); 4 Jun 2008 13:00:19 -0000 Received: (qmail 21790 invoked by uid 22791); 4 Jun 2008 13:00:19 -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; Wed, 04 Jun 2008 13:00:01 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id m54CxmRV015965 for ; Wed, 4 Jun 2008 13:59:49 +0100 Received: from yw-out-2324.google.com (ywt2.prod.google.com [10.192.20.2]) by zps35.corp.google.com with ESMTP id m54Cxl6w028186 for ; Wed, 4 Jun 2008 05:59:48 -0700 Received: by yw-out-2324.google.com with SMTP id 2so116423ywt.89 for ; Wed, 04 Jun 2008 05:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.52.2 with SMTP id z2mr45113ybz.49.1212584387482; Wed, 04 Jun 2008 05:59:47 -0700 (PDT) In-Reply-To: <96A87E23-CD76-41E3-A4BD-DD399C847F17@apple.com> References: <96A87E23-CD76-41E3-A4BD-DD399C847F17@apple.com> Date: Wed, 04 Jun 2008 13:00:00 -0000 Message-ID: Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA From: Diego Novillo To: Chris Lattner Cc: gcc@gcc.gnu.org, Kenneth Zadeck , Jan Hubicka , Rafael Espindola , Ollie Wild , 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/msg00054.txt.bz2 On Tue, Jun 3, 2008 at 22:26, Chris Lattner wrote: > and whopr here. Is LTO the mode "normal people" will use, and whopr is the > mode where "people with huge clusters" will use? Will LTO/whopr support > useful optimization on common multicore machines? As Ollie said, WHOPR is just an extension on the LTO framework to cater for scalability when building large applications. As such, when building large applications we expect not to be able to apply IPA passes that rely on having the whole program callgraph and bodies loaded in memory. However, WHOPR does not limit IPA passes to summary-only. That's why you see the distinction between IPA_PASS and SIMPLE_IPA_PASS in the pass manager. > Are you focusing on inlining here as a specific example, or is this the only > planned IPA optimization that can use summaries? It seems unfortunate to No. Just the first pass that we are going to concentrate for the initial implementation. >> == Design Philosophy == >> * The implementation provides complete transparency. Developers >> should be able to take advantage of LTO without having to modify >> existing build systems and/or Makefiles, all that's needed is to add >> an LTO option (-flto). > > Ok. How do you handle merging of optimization info? If I build one .o > file with -Os and one with -O3 who wins or what does this mean? If I build > one with -ffast-math and one without, does the right thing happen? Right now, mixed optimization flags will likely cause trouble. We have not really talked about this issue in detail. I expect many/most of these issues will be orthogonal to the driver, though. We've talked a bit about different ways of encoding the options into the IR, but there is nothing concrete yet. It's in my list of things to discuss at the next BoF. > Also, where does debug info (i.e. DWARF for -g) get stored? I'm not talking > about people debugging the compiler, I'm talking about people who want to > build an executable with debug info. In the .o file. We are generating regular .o files (for now). > Is there a specific reason you don't use the LLVM LTO interface? It seems > to be roughly the same as your proposed interface: Not really. This is mostly the first iteration. Rafael and Robert will be able to tell you much more about this. I'm not directly working on this aspect. Diego.