From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8618 invoked by alias); 11 Dec 2015 13:00:46 -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 8599 invoked by uid 89); 11 Dec 2015 13:00:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD 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, 11 Dec 2015 13:00:44 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40833) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1a7NJS-000782-Im for gcc-patches@gnu.org; Fri, 11 Dec 2015 08:00:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a7NJN-0005rW-Aq for gcc-patches@gnu.org; Fri, 11 Dec 2015 08:00:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:55626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7NJN-0005qw-32 for gcc-patches@gnu.org; Fri, 11 Dec 2015 08:00:37 -0500 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4E13CAC08; Fri, 11 Dec 2015 13:00:36 +0000 (UTC) Date: Fri, 11 Dec 2015 13:00:00 -0000 From: Richard Biener To: Tom de Vries cc: Jakub Jelinek , "gcc-patches@gnu.org" Subject: Re: [PATCH, 4/16] Implement -foffload-alias In-Reply-To: <566AC56E.8050701@mentor.com> Message-ID: References: <5640BD31.2060602@mentor.com> <5640C560.1000007@mentor.com> <20151111110034.GF5675@tucnak.redhat.com> <5644B84D.6050504@mentor.com> <5645C33B.9080802@mentor.com> <20151113113938.GM5675@tucnak.redhat.com> <566AC56E.8050701@mentor.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 195.135.220.15 X-SW-Source: 2015-12/txt/msg01260.txt.bz2 On Fri, 11 Dec 2015, Tom de Vries wrote: > On 13/11/15 12:39, Jakub Jelinek wrote: > > 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. > > Hi, > > This work-in-progress patch allows me to use IPA PTA information in the > kernels pass group. > > Since: > - I'm running IPA PTA before ealias, and IPA PTA does not interpret > restrict, and > - compute_may_alias doesn't run if IPA PTA information is present > I needed to convince ealias to do the restrict clique/base annotation. > > It would be more logical to fit IPA PTA after ealias, but one is an IPA pass, > the other a regular one-function pass, so I would have to split the containing > pass groups pass_all_early_optimizations and pass_local_optimization_passes. > I'll give that a try now. > > Any comments? I don't think you want to run IPA PTA before early optimizations, it (and ealias) rely on some initial cleanup to do anything meaningful with well-spent ressources. The local PTA "hack" also looks more like a waste of resources, but well ... teaching IPA PTA to honor restrict might be an impossible task though I didn't think much about it other than handling it only for nonlocal_p functions (for others we should see all incoming args if IPA PTA works optimally). The restrict tags will leak all over the place of course and in the end no meaningful cliques may remain. Richard.