From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39534 invoked by alias); 23 Jan 2016 18:28:38 -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 39523 invoked by uid 89); 23 Jan 2016 18:28:38 -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 spammy=Hx-languages-length:1773, Canonicalize, sk:access_, HX-detected-operating-system:Windows 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; Sat, 23 Jan 2016 18:28:37 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47264) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aN2vK-0000HG-Pu for gcc-patches@gnu.org; Sat, 23 Jan 2016 13:28:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN2vH-0002IM-8y for gcc-patches@gnu.org; Sat, 23 Jan 2016 13:28:34 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:36103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN2vH-0002IE-3n for gcc-patches@gnu.org; Sat, 23 Jan 2016 13:28:31 -0500 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1aN2vD-00068r-S7 from Tom_deVries@mentor.com ; Sat, 23 Jan 2016 10:28:28 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Sat, 23 Jan 2016 18:28:26 +0000 Subject: Re: [PATCH, PR69110] Don't return NULL access_fns in dr_analyze_indices To: Sebastian Pop , "gcc-patches@gnu.org" , Richard Biener References: <5694CF85.1020708@mentor.com> <5694F5BA.7030207@mentor.com> <5695436D.4000003@mentor.com> <56A16E1E.30304@mentor.com> From: Tom de Vries Message-ID: <56A3C647.2040906@mentor.com> Date: Sat, 23 Jan 2016 18:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 X-SW-Source: 2016-01/txt/msg01818.txt.bz2 On 23/01/16 18:39, Sebastian Pop wrote: > diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c > index a40f40d..7ff5db7 100644 > --- a/gcc/tree-data-ref.c > +++ b/gcc/tree-data-ref.c > @@ -1023,6 +1023,10 @@ dr_analyze_indices (struct data_reference *dr, > loop_p nest, loop_p loop) > build_int_cst (reference_alias_ptr_type (ref), 0)); > } > > + /* Ensure that DR_NUM_DIMENSIONS (dr) != 0. */ > + if (access_fns == vNULL) > + access_fns.safe_push (integer_zero_node); > + > DR_BASE_OBJECT (dr) = ref; > DR_ACCESS_FNS (dr) = access_fns; > } > > This code adds a data reference with an access function 0 for all data > references > that cannot be analyzed by the data reference analysis. Let's move > this check under > the check for DECL_P (ref) and this fixes the check in graphite: > > diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c > index a40f40d..862589b 100644 > --- a/gcc/tree-data-ref.c > +++ b/gcc/tree-data-ref.c > @@ -1018,12 +1018,15 @@ dr_analyze_indices (struct data_reference *dr, > loop_p nest, loop_p loop) > else if (DECL_P (ref)) > { > /* Canonicalize DR_BASE_OBJECT to MEM_REF form. */ > ref = build2 (MEM_REF, TREE_TYPE (ref), > build_fold_addr_expr (ref), > build_int_cst (reference_alias_ptr_type (ref), 0)); > + > + if (access_fns == vNULL) > + access_fns.safe_push (integer_zero_node); > } > > DR_BASE_OBJECT (dr) = ref; > DR_ACCESS_FNS (dr) = access_fns; > } > > Ok with this change. > Hi Sebastian, That was my original patch, and Richard commented: 'I think avoiding a NULL access_fns is ok but it should be done unconditionally, not only for the DECL_P case'. In order words, he asked me to do the exact opposite of the change you now propose. Thanks, - Tom