From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11492 invoked by alias); 23 Aug 2013 12:37:00 -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 11483 invoked by uid 89); 23 Aug 2013 12:36:59 -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; Fri, 23 Aug 2013 12:36:59 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7NCafso023812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Aug 2013 08:36:41 -0400 Received: from zalov.cz (vpn1-4-247.ams2.redhat.com [10.36.4.247]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7NCadBD022138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 08:36:41 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r7NCadYi005270; Fri, 23 Aug 2013 14:36:39 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r7NCacVI005269; Fri, 23 Aug 2013 14:36:38 +0200 Date: Fri, 23 Aug 2013 15:06:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Ilya Verbin , Uday Khedker , 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: <20130823123638.GL1814@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20130815133639.GA42355@msticlxl57.ims.intel.com> <20130815134437.GB1814@tucnak.redhat.com> <4df844f6-f385-4e63-9413-8ea341992b77@email.android.com> <20130823105527.GA6976@msticlxl57.ims.intel.com> <85e37f42-69fe-4bbf-bf1d-f73194e7c444@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85e37f42-69fe-4bbf-bf1d-f73194e7c444@email.android.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-08/txt/msg00277.txt.bz2 On Fri, Aug 23, 2013 at 02:24:42PM +0200, Richard Biener wrote: > >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? > > No, as you will refer to the symbol with the target code from the host > code you need a single unified symtab. I really think you want two symtabs rather than a unified symtab, or just stream a subset of the host symtab into the .gnu.target_lto section. The thing is, the target code (functions, vars, outlined bodies) is a strict subset of the host code (because as a fallback, everything needs to be able to run on the host), but when not compiling originally with -flto, we IMHO should stream just the target subset, not everything (and for -flto stream both the target subset into one section and everything (host code) as we do right now, either with fat or slim lto objects). I think we shouldn't require that you can use -fopenmp and acceleration only if you compile host code with -flto. The target code generally can't call into the host code, and for the other direction at least for Intel MIC it is done by symbol lookup (you tell COI library to upload a binary or shared library from file or memory to the target device and then you tell it to invoke some named function). Jakub