From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26844 invoked by alias); 23 Aug 2013 10:55:59 -0000 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 Received: (qmail 26834 invoked by uid 89); 23 Aug 2013 10:55:58 -0000 X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.2 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 10:55:58 +0000 Received: by mail-pa0-f45.google.com with SMTP id bg4so531330pad.18 for ; Fri, 23 Aug 2013 03:55:56 -0700 (PDT) X-Received: by 10.66.255.104 with SMTP id ap8mr20401186pad.53.1377255356723; Fri, 23 Aug 2013 03:55:56 -0700 (PDT) Received: from msticlxl57.ims.intel.com ([192.55.54.41]) by mx.google.com with ESMTPSA id zi1sm20749334pbb.28.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 03:55:55 -0700 (PDT) Date: Fri, 23 Aug 2013 13:15:00 -0000 From: Ilya Verbin To: Richard Biener , Jakub Jelinek , Uday Khedker Cc: hubicka@ucw.cz, rth@redhat.com, kirill.yukhin@gmail.com, "Michael V. Zolotukhin" , gcc@gcc.gnu.org Subject: Re: Questions about LTO infrastructure and pragma omp target Message-ID: <20130823105527.GA6976@msticlxl57.ims.intel.com> References: <20130815133639.GA42355@msticlxl57.ims.intel.com> <20130815134437.GB1814@tucnak.redhat.com> <4df844f6-f385-4e63-9413-8ea341992b77@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4df844f6-f385-4e63-9413-8ea341992b77@email.android.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-08/txt/msg00272.txt.bz2 Jakub, Richard, Uday, Thanks for your answers. On 15 Aug 20:59, Richard Biener wrote: > Alternatively you make lto-wrapper aware of this which means that WPA stage would emit extra partitions that it marks for lto-wrapper. > > That sounds better than another plugin to me. Of course WPA time might be too limiting. Otoh the idea of multiple WPA stages, aka iterating lto could be picked up to have a late WPA stage. > > Richard. I'm trying to implement the approach with modified lto-wrapper. Suppose we have a bytecode of the routine foo, streamed during ompexp pass into some section, say .gnu.omptarget_foo. In function lto.c:do_whole_program_analysis() an extra partition should be created, that will contain bytecode from .gnu.omptarget_foo, right? As far as I understood, in addition to the bytecode of foo, we should also stream extra symtab_nodes, and read them somewhere in lto-cgraph.c:input_symtab(). This means we should maintain 2 symtabs inside WPA stage - original for host and new for target? Richard, also what do you mean by "WPA time might be too limiting"? Thanks, -- Ilya