From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32112 invoked by alias); 24 Oct 2014 14:20:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 32100 invoked by uid 89); 24 Oct 2014 14:20:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 24 Oct 2014 14:20:41 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9OEKbfu017522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Oct 2014 10:20:37 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9OEKYEC016832 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Oct 2014 10:20:35 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9OEKWLu025719; Fri, 24 Oct 2014 16:20:32 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9OEKSjC025718; Fri, 24 Oct 2014 16:20:28 +0200 Date: Fri, 24 Oct 2014 14:29:00 -0000 From: Jakub Jelinek To: Ilya Verbin Cc: Richard Biener , Thomas Schwinge , Jan Hubicka , gcc-patches@gcc.gnu.org, Kirill Yukhin , Ilya Tocar , Andrey Turetskiy , Bernd Schmidt Subject: Re: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming Message-ID: <20141024142028.GD10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140927181647.GA1819@msticlxl57.ims.intel.com> <20140929011014.GA11758@kam.mff.cuni.cz> <20140929173704.GA7526@msticlxl57.ims.intel.com> <878ul172w5.fsf@schwinge.name> <20141001161332.GB54978@msticlxl57.ims.intel.com> <20141020111935.GA9362@msticlxl57.ims.intel.com> <20141024141601.GA62562@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141024141601.GA62562@msticlxl57.ims.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02562.txt.bz2 On Fri, Oct 24, 2014 at 06:16:01PM +0400, Ilya Verbin wrote: > We have to set the global have_offload flag in few places in omp-low.c and in FE > (c/c-decl.c:c_decl_attributes, fortran/trans-common.c:build_common_decl, > fortran/trans-decl.c:add_attributes_to_decl). > This way looks for me a bit more complicated than the current approach. > > Actually, we could follow Jakub's suggestion of caching the attribute in a bit > field, and set the global have_offload flag on the run without any changes in > FE. However, I don't know a suitable place for it. If you agree with the > approach, could you please specify the place? Can't you do that when creating the cgraph or varpool nodes? I'd expect the attribute to be already present on the decls at those spots. Jakub