From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14433 invoked by alias); 13 Nov 2015 11:39:57 -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 14412 invoked by uid 89); 13 Nov 2015 11:39:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 13 Nov 2015 11:39:55 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53194) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZxCht-00015R-Bw for gcc-patches@gnu.org; Fri, 13 Nov 2015 06:39:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxChp-0007qB-3x for gcc-patches@gnu.org; Fri, 13 Nov 2015 06:39:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxCho-0007q0-Un for gcc-patches@gnu.org; Fri, 13 Nov 2015 06:39:49 -0500 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 (Postfix) with ESMTPS id BC0A08F232; Fri, 13 Nov 2015 11:39:45 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tADBdhnA003561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Nov 2015 06:39:45 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id tADBdfVX002500; Fri, 13 Nov 2015 12:39:41 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id tADBdciY002499; Fri, 13 Nov 2015 12:39:38 +0100 Date: Fri, 13 Nov 2015 11:39:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Tom de Vries , "gcc-patches@gnu.org" Subject: Re: [PATCH, 4/16] Implement -foffload-alias Message-ID: <20151113113938.GM5675@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5640BD31.2060602@mentor.com> <5640C560.1000007@mentor.com> <20151111110034.GF5675@tucnak.redhat.com> <5644B84D.6050504@mentor.com> <5645C33B.9080802@mentor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01672.txt.bz2 On Fri, Nov 13, 2015 at 12:29:51PM +0100, Richard Biener wrote: > > thanks for the explanation. Filed as PR68331 - '[meta-bug] fipa-pta issues'. > > > > Any feedback on the '#pragma GCC offload-alias=' bit above? > > Is that sort of what you had in mind? > > Yes. Whether that makes sense is another question of course. You can > annotate memory references with MR_DEPENDENCE_BASE/CLIQUE yourself > as well if you know dependences without the users intervention. I really don't like even the GCC offload-alias, I just don't see anything special on the offload code. Not to mention that the same issue is already with other outlined functions, like OpenMP tasks or parallel regions, those aren't offloaded, yet they can suffer from worse alias/points-to analysis too. We simply have some compiler internal interface between the caller and callee of the outlined regions, each interface in between those has its own structure type used to communicate the info; we can attach attributes on the fields, or some flags to indicate some properties interesting from aliasing POV. We don't really need to perform full IPA-PTA, perhaps it would be enough to a) record somewhere in cgraph the relationship in between such callers and callees (for offloading regions we already have "omp target entrypoint" attribute on the callee and a singler caller), tell LTO if possible not to split those into different partitions if easily possible, and then just for these pairs perform aliasing/points-to analysis in the caller and the result record using cliques/special attributes/whatever to the callee side, so that the callee (outlined OpenMP/OpenACC/Cilk+ region) can then improve its alias analysis. Jakub