From patchwork Thu Nov 24 12:32:52 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razya Ladelsky X-Patchwork-Id: 127493 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 334E91007D7 for ; Thu, 24 Nov 2011 23:33:19 +1100 (EST) Received: (qmail 21033 invoked by alias); 24 Nov 2011 12:33:15 -0000 Received: (qmail 21024 invoked by uid 22791); 24 Nov 2011 12:33:14 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, TW_WD X-Spam-Check-By: sourceware.org Received: from mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (194.196.100.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Nov 2011 12:33:00 +0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id pAOCWwNL020433 for ; Thu, 24 Nov 2011 12:32:58 GMT Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAOCWvjr2609328 for ; Thu, 24 Nov 2011 12:32:57 GMT Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAOCWvJT008712 for ; Thu, 24 Nov 2011 05:32:57 -0700 Received: from d06ml319.portsmouth.uk.ibm.com (d06ml319.portsmouth.uk.ibm.com [9.149.76.146]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pAOCWvHe008707; Thu, 24 Nov 2011 05:32:57 -0700 In-Reply-To: <20111121172510.GK27242@tyan-ft48-01.lab.bos.redhat.com> References: <20111121125707.GG27242@tyan-ft48-01.lab.bos.redhat.com> <20111121135915.GH27242@tyan-ft48-01.lab.bos.redhat.com> <20111121150754.GJ27242@tyan-ft48-01.lab.bos.redhat.com> <20111121172510.GK27242@tyan-ft48-01.lab.bos.redhat.com> To: Jakub Jelinek Cc: GCC Patches , Richard Guenther MIME-Version: 1.0 Subject: Re: [PATCH, take 2] Fix PR tree-optimization/49960 , Fix self data dependence X-KeepSent: 40CD4C0B:22310E4B-C2257952:0044D957; type=4; name=$KeepSent From: Razya Ladelsky Message-ID: Date: Thu, 24 Nov 2011 14:32:52 +0200 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Jakub Jelinek wrote on 21/11/2011 07:25:10 PM: > From: Jakub Jelinek > To: Razya Ladelsky/Haifa/IBM@IBMIL > Cc: GCC Patches , Richard Guenther > > Date: 21/11/2011 07:25 PM > Subject: Re: [PATCH, take 2] Fix PR tree-optimization/49960 ,Fix > self data dependence > > On Mon, Nov 21, 2011 at 06:56:55PM +0200, Razya Ladelsky wrote: > > I have some non-affine cases for which compute_affine_dependence is called > > (as it is called for > > ALL dependences from compte_all_depepndences()), and no harm is done. > > I looked a little bit closer into the code, and this is what happens for > > non affine accesses: > > > > initialize_data_dependence_relation() assigns > > DDR_ARE_DEPENDENT (res) = chrec_dont_know for the dr. > > It can be chrec_known too (that's actually the only interesting case for us > unless it is a read-read ddr), but you're right that likely > object_address_invariant_in_loop_p should be false. > > > Then, compute_affine_depepndence() > > tests if (DDR_ARE_DEPENDENT (ddr) == NULL_TREE), and does nothing > > otherwise. > > Since the dr was initialized with chrec_dont_know, no harm is done. > > > > Anyway, since it is useless for your gather case, I'll just remove it, > > along with compute_self_dependence(). > > > > OK? > > Yes, patch preapproved. > > Jakub > Hi, Going to commit this patch today. I bootstrapped and regtested on ppc64-suse-linux. ChangeLog: * tree-data-ref.c (initialize_data_dependence_relation): Update comment for the self dependence case. (compute_self_dependence): Remove. * tree-vect-data-refs.c (vect_analyze_data_refs): Remove call to compute_self_dependenc. Thanks, Razya = Index: tree-data-ref.c =================================================================== --- tree-data-ref.c (revision 181675) +++ tree-data-ref.c (working copy) @@ -1385,8 +1385,7 @@ initialize_data_dependence_relation (struct data_r return res; } - /* When the references are exactly the same, don't spend time doing - the data dependence tests, just initialize the ddr and return. */ + /* The case where the references are exactly the same. */ if (operand_equal_p (DR_REF (a), DR_REF (b), 0)) { if (loop_nest @@ -4132,19 +4131,6 @@ compute_affine_dependence (struct data_dependence_ fprintf (dump_file, ")\n"); } -/* This computes the dependence relation for the same data - reference into DDR. */ - -void -compute_self_dependence (struct data_dependence_relation *ddr) -{ - if (DDR_ARE_DEPENDENT (ddr) != NULL_TREE) - return; - - if (DDR_LOOP_NEST (ddr)) - compute_affine_dependence (ddr, VEC_index (loop_p, DDR_LOOP_NEST (ddr), 0)); -} - /* Compute in DEPENDENCE_RELATIONS the data dependence graph for all the data references in DATAREFS, in the LOOP_NEST. When COMPUTE_SELF_AND_RR is FALSE, don't compute read-read and self Index: tree-vect-data-refs.c =================================================================== --- tree-vect-data-refs.c (revision 181675) +++ tree-vect-data-refs.c (working copy) @@ -3122,7 +3122,6 @@ vect_analyze_data_refs (loop_vec_info loop_vinfo, ddr = VEC_index (ddr_p, ddrs, k); gcc_assert (DDR_A (ddr) == olddr && DDR_B (ddr) == olddr); newddr = initialize_data_dependence_relation (dr, dr, nest); - compute_self_dependence (newddr); VEC_replace (ddr_p, ddrs, k, newddr); free_dependence_relation (ddr); VEC_replace (data_reference_p, datarefs, i, dr);