From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2671 invoked by alias); 8 Jan 2015 14:12:07 -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 2660 invoked by uid 89); 8 Jan 2015 14:12:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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; Thu, 08 Jan 2015 14:12:05 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t08EBwPx030336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 8 Jan 2015 09:11:58 -0500 Received: from tucnak.zalov.cz (ovpn-116-64.ams2.redhat.com [10.36.116.64]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t08EBu5f008661 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 8 Jan 2015 09:11:57 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t08EBrqr008593; Thu, 8 Jan 2015 15:11:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t08EBn5o008592; Thu, 8 Jan 2015 15:11:49 +0100 Date: Thu, 08 Jan 2015 14:12:00 -0000 From: Jakub Jelinek To: Bernd Schmidt , Richard Biener , Jan Hubicka Cc: gcc-patches@gcc.gnu.org, neil@daikokuya.co.uk.zalov.cz, joseph@codesourcery.com, Thomas Schwinge , Julian Brown , Cesar Philippidis Subject: Re: LTO streaming of TARGET_OPTIMIZE_NODE Message-ID: <20150108141149.GC1405@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20141113040652.GB1984@kam.mff.cuni.cz> <546DDE1C.6060203@t-online.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546DDE1C.6060203@t-online.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00376.txt.bz2 On Thu, Nov 20, 2014 at 01:27:08PM +0100, Bernd Schmidt wrote: > On 11/13/2014 05:06 AM, Jan Hubicka wrote: > >this patch adds infrastructure for proper streaming and merging of > >TREE_TARGET_OPTION. > > This breaks the offloading path via LTO since it introduces an > incompatibility in LTO format between host and offload machine. > > A very quick patch to fix it is below - the OpenACC testcase I was using > seems to be working again with this. Thoughts, suggestions? I actually think this patch makes a lot of sense. Target option nodes by definition are target specific, generally there is no mapping between host and offloading target features. So, the host target options are not useful to the offloading target. And, because the amount of bits streamed is also target specific, say x86_64 will have different and incompatible cl_target_option_stream_{out,in} from nvptx, and even for Intel MIC offloading it doesn't make much sense, what CPU is certain function targetting doesn't necessarily have any relation to the Intel MIC that will offload it. I agree the strcmp (section_name_prefix, LTO_SECTION_NAME_PREFIX) == 0 checks in the patch aren't very nice, that could be replaced by some bool flag alongside of section_name_prefix that would be set where section_name_prefix is set: cgraphunit.c: section_name_prefix = OFFLOAD_SECTION_NAME_PREFIX; cgraphunit.c: section_name_prefix = LTO_SECTION_NAME_PREFIX; lto-streamer.c:const char *section_name_prefix = LTO_SECTION_NAME_PREFIX; lto/lto.c: section_name_prefix = OFFLOAD_SECTION_NAME_PREFIX; (call it say bool lto_stream_offload_p ?). Also note that the patch fixes all the current regressions in Intel MIC (emulated) offloading caused by the r218767 Jakub