From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37791 invoked by alias); 23 Jan 2016 18:45:11 -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 37781 invoked by uid 89); 23 Jan 2016 18:45:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:create, Hx-spam-relays-external:f8b0, H*RU:f8b0, teach 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:45:09 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49299) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aN3BK-000749-KM for gcc-patches@gnu.org; Sat, 23 Jan 2016 13:45:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN3BJ-0005gw-3H for gcc-patches@gnu.org; Sat, 23 Jan 2016 13:45:06 -0500 Received: from mail-ig0-x22e.google.com ([2607:f8b0:4001:c05::22e]:34146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN3BI-0005fL-Tj for gcc-patches@gnu.org; Sat, 23 Jan 2016 13:45:05 -0500 Received: by mail-ig0-x22e.google.com with SMTP id ik10so11460318igb.1 for ; Sat, 23 Jan 2016 10:45:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/941W4+6mU7SZWwl5m66ZA8gLc+UlrQMAPZKERyBmJY=; b=gGkLM0ULKLree9GezYXiQp3MO6vnKVBuHflP0HurmKZqFmp09KMhqPY98f6epwk6nZ j7AC8h2albrCkz+eNkUzu3+XyBgLI5gz11LT3+/wFKs9Ctl7+mC7vgWz2Bc74LFkjpMM zrGQHLcZHd95aL+bitOgBmZAcMIWpl9irWBB82l5Fkvijh02fmXutPxZ1JsMGUSvf9+e nJWjKO9sV9szNMuwlSN+Dg91YFlMjthuS3XXHNm5fmmblOp7XL12a7Sy0a8FQYuxia9E klFNUUNPepbAoo0/FMKQaIN72C3xzL6DoprvNaSyLdio9IR09tnNaUaq/FxubM+HGw68 NaNw== X-Gm-Message-State: AG10YOQYtQ4qZavRn6jxVz+mF9PlVpnTnObjliiSvBmEFe80LEbPQkfRqsH9LTnNvyzGj3pnyzLkWuaQymnIKw== X-Received: by 10.50.26.5 with SMTP id h5mr9421384igg.25.1453574703077; Sat, 23 Jan 2016 10:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.97 with HTTP; Sat, 23 Jan 2016 10:44:23 -0800 (PST) In-Reply-To: <56A3C647.2040906@mentor.com> References: <5694CF85.1020708@mentor.com> <5694F5BA.7030207@mentor.com> <5695436D.4000003@mentor.com> <56A16E1E.30304@mentor.com> <56A3C647.2040906@mentor.com> From: Sebastian Pop Date: Sat, 23 Jan 2016 18:45:00 -0000 Message-ID: Subject: Re: [PATCH, PR69110] Don't return NULL access_fns in dr_analyze_indices To: Tom de Vries Cc: "gcc-patches@gnu.org" , Richard Biener Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c05::22e X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01819.txt.bz2 On Sat, Jan 23, 2016 at 12:28 PM, Tom de Vries wrote: > 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. > In the case of a DECL_P it is correct to say that it has an access function of 0. In the graphite testcase it is not correct to say that the access function for a given data reference is zero: we only initialize access_fns in the case of a polynomial chrec: if (TREE_CODE (ref) == MEM_REF) { op = TREE_OPERAND (ref, 0); access_fn = analyze_scalar_evolution (loop, op); access_fn = instantiate_scev (before_loop, loop, access_fn); if (TREE_CODE (access_fn) == POLYNOMIAL_CHREC) { [...] access_fns.safe_push (access_fn); } } In all other cases we may not have a representation of the access functions. It is incorrect to initialize to "A[0]" all those data references that cannot be analyzed. If needed, instead of returning vNULL, one could initialize the vector to empty: if (access_fns == vNULL) access_fns.create (0); and that would be correct, though it would not teach the dependence analysis how to deal with the global variable access function in pr69110. I think the fix is to add the zero subscript only for DECL_P (ref). Sebastian