From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9681 invoked by alias); 21 Oct 2011 09:06:40 -0000 Received: (qmail 9666 invoked by uid 22791); 21 Oct 2011 09:06:39 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Oct 2011 09:06:24 +0000 Received: by ggnj1 with SMTP id j1so2436704ggn.20 for ; Fri, 21 Oct 2011 02:06:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.44.9 with SMTP id a9mr911031obm.61.1319187983604; Fri, 21 Oct 2011 02:06:23 -0700 (PDT) Received: by 10.182.12.202 with HTTP; Fri, 21 Oct 2011 02:06:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 09:26:00 -0000 Message-ID: Subject: Fwd: [patch] Fix PR tree-optimization/49960 ,Fix self data dependence From: Richard Guenther To: GCC Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg01937.txt.bz2 Forwarded to the list, gcc.gnu.org doesn't like gmail anymore. ---------- Forwarded message ---------- From: Richard Guenther Date: Fri, Oct 21, 2011 at 11:03 AM Subject: Re: [patch] Fix PR tree-optimization/49960 ,Fix self data dependen= ce To: Razya Ladelsky Cc: gcc-patches@gcc.gnu.org, gcc-patches-owner@gcc.gnu.org, Sebastian Pop On Wed, Oct 19, 2011 at 5:42 PM, Razya Ladelsky wrote: > gcc-patches-owner@gcc.gnu.org wrote on 17/10/2011 09:03:59 AM: > >> From: Richard Guenther >> To: Razya Ladelsky/Haifa/IBM@IBMIL >> Cc: gcc-patches@gcc.gnu.org, Sebastian Pop >> Date: 17/10/2011 09:04 AM >> Subject: Re: [patch] Fix PR tree-optimization/49960 ,Fix self data > dependence >> Sent by: gcc-patches-owner@gcc.gnu.org >> >> On Mon, Oct 17, 2011 at 8:23 AM, Razya Ladelsky > wrote: >> > This patch fixes the failures described in >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D49960 >> > It also fixes bzips when run with autopar enabled. >> > >> > In both cases the self dependences are not handled correctly. >> > In the first case, a non affine access is analyzed: >> > in the second, the distance vector is not calculated correctly (the >> > distance vector considered for for self dependences is always > (0,0,...)) >> > >> > As =A0a result, the loops get wrongfully parallelized. >> > >> > The patch avoids the special handling of =A0self dependences, and > analyzes >> > all dependences in the same way. Specific adjustments >> > and support for the self dependence cases were made. >> >> Can you elaborate on >> >> @@ -3119,8 +3135,11 @@ add_other_self_distances (struct > data_dependence_r >> =A0 =A0 =A0 =A0 { >> =A0 =A0 =A0 =A0 =A0 if (DDR_NUM_SUBSCRIPTS (ddr) !=3D 1) >> =A0 =A0 =A0 =A0{ >> - =A0 =A0 =A0 =A0DDR_ARE_DEPENDENT (ddr) =3D chrec_dont_know; >> - =A0 =A0 =A0 =A0return; >> + =A0 =A0 =A0 =A0if (DDR_NUM_SUBSCRIPTS (ddr) !=3D 2 || !integer_zerop > (DR_ACCESS_FN >> (DDR_A (ddr), 1))) >> + =A0 =A0 =A0 =A0 =A0{ >> + =A0 =A0 =A0 =A0 =A0 =A0DDR_ARE_DEPENDENT (ddr) =3D chrec_dont_know; >> + =A0 =A0 =A0 =A0 =A0 =A0return; >> + =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0} >> >> =A0 =A0 =A0 =A0 =A0 access_fun =3D DR_ACCESS_FN (DDR_A (ddr), 0); >> >> ? =A0It needed a comment before, and now so even more. >> >> The rest of the patch is ok, I suppose the above hunk is to enhance >> something, not >> to fix the bug? > > For fortran code like: > > =A0 =A0 =A0DO 140 J=3D1,MB > =A0 =A0 =A0 =A0 DO 130 K=3D1,NA > =A0 =A0 =A0 =A0 =A0 =A0BKJ=3DB(K,J) > =A0 =A0 =A0 =A0 =A0 =A0IF(BKJ.EQ.ZERO) GO TO 130 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 DO 120 I=3D1,MA > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0C(I,J)=3DC(I,J)+A(K,I)*BKJ > =A0120 =A0 =A0 =A0 =A0 =A0CONTINUE > =A0130 =A0 =A0CONTINUE > =A0140 CONTINUE > =A0 =A0 =A0RETURN > > > The access functions for the C(i j) self dependence are: > > (Data Dep: > #(Data Ref: > # =A0bb: 9 > # =A0stmt: D.1427_79 =3D *c_78(D)[D.1426_77]; > # =A0ref: *c_78(D)[D.1426_77]; > # =A0base_object: *c_78(D); > # =A0Access function 0: {{(stride.12_25 + 1) + offset.13_36, +, > stride.12_25}_1, +, 1}_3 > # =A0Access function 1: 0B > #) > #(Data Ref: > # =A0bb: 9 > # =A0stmt: *c_78(D)[D.1426_77] =3D D.1433_88; > # =A0ref: *c_78(D)[D.1426_77]; > # =A0base_object: *c_78(D); > # =A0Access function 0: {{(stride.12_25 + 1) + offset.13_36, +, > stride.12_25}_1, +, 1}_3 > # =A0Access function 1: 0B > #) > > > Two dimesions are created to describe C(i j) although there's no need for > access function 1 which is just 0B. > > > If this was a C code, we would have these two access functions for > C[i][j]: > > (Data Dep: > #(Data Ref: > # =A0bb: 5 > # =A0stmt: t_10 =3D C[i_33][j_37]; > # =A0ref: C[i_33][j_37]; > # =A0base_object: C > # =A0Access function 0: {3, +, 1}_3 > # =A0Access function 1: {3, +, 1}_2 > #) > #(Data Ref: > # =A0bb: 5 > # =A0stmt: C[i_33][j_37] =3D D.3852_15; > # =A0ref: C[i_33][j_37]; > # =A0base_object: C > # =A0Access function 0: {3, +, 1}_3 > # =A0Access function 1: {3, +, 1}_2 > #) > > > In order to handle the Fortran data accesses, even for simple cases as > above, > I would need to handle multivariate accesses. > The data dependence analysis doesn't know how to handle such dependences > if there's more than one subscript. > The above Frotran code doesn't actually have two subscripts, but one, and > thus should be handled. > > The reason this issue came up only with the changes of this patch is that > now > add_other_self_distances is called from build_classic_dist_vector, which > is called also for self dependences. > Before the patch, the distance vector for self dependences was always > determined as a vector of 0's, and build_classic_dist_vector > was not called. > > I hope it's clearer now, I will add a comment to the code, and submit it > before committing it. No, it's not clearer, because it is not clear why you need to add the hack instead of avoiding the 2nd access function. And iff you add the hack it needs a comment why zero should be special (any other constant would be the same I suppose). Btw, your fortran example does not compile and I don't believe the issue is still present after my last changes to dr_analyze_indices. =A0So, did you verify this on trunk? Richard. > Thanks, > Razya > > >> >> Thanks, >> Richard. >> >> > Bootstrap and testsuite pass successfully for ppc64-redhat-linux. >> > >> > OK for trunk? >> > Thank you, >> > Razya >> > >> > >> > ChangeLog: >> > >> > =A0 =A0 =A0 =A0PR tree-optimization/49960 >> > =A0 =A0 =A0 =A0* tree-data-ref.c (compute_self_dependence): Remove. >> > =A0 =A0 =A0 =A0 =A0 =A0 (initialize_data_dependence_relation): Add int= ializations. >> > Remove compute_self_dependence. >> > =A0 =A0 =A0 =A0 =A0 =A0 (add_other_self_distances): Add support for tw= o dimensions > if >> > the second is zero. >> > =A0 =A0 =A0 =A0 =A0 =A0 (compute_affine_dependence): Remove the > !DDR_SELF_REFERENCE >> > condition. >> > =A0 =A0 =A0 =A0 =A0 =A0 (compute_all_dependences): Remove call to >> > compute_self_dependence. Add call to compute_affine_dependence >> >> > testsuite/ChangeLog: >> > >> > =A0 =A0 =A0 =A0PR tree-optimization/49660 >> > =A0 =A0 =A0 =A0* gcc.dg/autopar/pr49660.c: New test. >> > =A0 =A0 =A0 =A0 =A0 * gcc.dg/autopar/pr49660-1.c: New test. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >