From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8294 invoked by alias); 15 Aug 2013 13:44:43 -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 8284 invoked by uid 89); 15 Aug 2013 13:44:42 -0000 X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 15 Aug 2013 13:44:42 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7FDiekW001010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Aug 2013 09:44:40 -0400 Received: from zalov.cz (vpn1-7-127.ams2.redhat.com [10.36.7.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7FDicJQ008069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2013 09:44:40 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r7FDic3U025036; Thu, 15 Aug 2013 15:44:38 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r7FDibeu025035; Thu, 15 Aug 2013 15:44:37 +0200 Date: Thu, 15 Aug 2013 15:00:00 -0000 From: Jakub Jelinek To: Ilya Verbin Cc: hubicka@ucw.cz, rth@redhat.com, kirill.yukhin@gmail.com, gcc@gcc.gnu.org Subject: Re: Questions about LTO infrastructure and pragma omp target Message-ID: <20130815134437.GB1814@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20130815133639.GA42355@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130815133639.GA42355@msticlxl57.ims.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-08/txt/msg00177.txt.bz2 On Thu, Aug 15, 2013 at 05:36:39PM +0400, Ilya Verbin wrote: > 2. The second question, regarding #pragma omp target implementation. > I'm going to reuse LTO approach in a prototype, that will produce 2 > binaries - for host and target architectures. Target binary will contain > functions outlined from omp target region and some infrastructure to run > them. > To produce 2 binaries we need to run gcc and ld twice. At the first run > gcc will generate object file, that contains optimized code for host and > GIMPLE for target. At the second run gcc will read the GIMPLE and > generate optimized code for target. > > So, the question is - what is the right place for the second run of gcc > and ld? Should I insert them into liblto_plugin.so? Or should I create > entirely new plugin, that will only call gcc and ld for target, without > performing any LTO optimizations for host? > Suggestions? The rough plan (partly discussed at the accelerator BoF) was that we would stream LTO bytecode into special section somewhere during ompexp pass or so (note, right now LTO streaming streams everything in a TU, we'd want to stream only the routines with "omp declare target" attribute, and outlined #pragma omp target regions, and vars referenced from it and types etc.), then have some other linker plugin (-fopenmp/-fopenacc) that would recognize these special sections and run lto1 on those (if not -flto in some mode that would just compile each TU separately or something), then we need to link it together and let the linker put it into some section of the host binary or shared library. Jakub