From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11605 invoked by alias); 2 Nov 2009 14:59:39 -0000 Received: (qmail 11590 invoked by uid 22791); 2 Nov 2009 14:59:38 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from portal.icerasemi.com (HELO pOrtaL.icerasemi.com) (213.249.204.90) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Nov 2009 14:59:34 +0000 X-ASG-Debug-ID: 1257173971-0d6f00050000-ThFIni X-Barracuda-URL: http://192.168.1.243:80/cgi-bin/mark.cgi Received: from Exchangevs.Icerasemi.com (cluster1.icerasemi.local [192.168.1.203]) by pOrtaL.icerasemi.com (Spam & Virus Firewall) with ESMTP id 80DF4ADAD0; Mon, 2 Nov 2009 14:59:31 +0000 (GMT) Received: from Exchangevs.Icerasemi.com (cluster1.icerasemi.local [192.168.1.203]) by pOrtaL.icerasemi.com with ESMTP id TL5PME0WWR4URENU; Mon, 02 Nov 2009 14:59:31 +0000 (GMT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: RFC PRE-ing REFERENCE expressions Subject: RE: RFC PRE-ing REFERENCE expressions Date: Mon, 02 Nov 2009 14:59:00 -0000 Message-ID: <4D60B0700D1DB54A8C0C6E9BE69163700C0A94F9@EXCHANGEVS.IceraSemi.local> References: <4D60B0700D1DB54A8C0C6E9BE69163700C0A8AC0@EXCHANGEVS.IceraSemi.local> <84fc9c000910300750o8534541ta836df6fcd479662@mail.gmail.com> From: "Rahul Kharche" To: "Richard Guenther" Cc: , , "sdkteam-gnu" X-Barracuda-Connect: cluster1.icerasemi.local[192.168.1.203] X-Barracuda-Start-Time: 1257173971 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13477 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00016.txt.bz2 Hi Richard, We would like to hang on to 4.4 for a little while. I was hoping I could grab only the alias analysis improvements from the trunk. Do you suspect this would be troublesome? Cheers, Rahul -----Original Message----- From: Richard Guenther [mailto:richard.guenther@gmail.com]=20 Sent: 30 October 2009 14:50 To: Rahul Kharche Cc: rguenth@gcc.gnu.org; gcc@gcc.gnu.org; sdkteam-gnu Subject: Re: RFC PRE-ing REFERENCE expressions On Fri, Oct 30, 2009 at 3:22 PM, Rahul Kharche wrote: > Hi Richi, > > Following up your suggestion on PR41488, I am continuing to test with > loop header copy before FRE in GCC 4.4.1. One regression I am trying > to tackle is from the test case below. > > typedef struct { > =A0int degree; > =A0int c[(256)]; > } swbcht_Polynomial; > > > typedef struct { > =A0int m; > =A0int n; > =A0const swbcht_Polynomial *primPoly; > =A0unsigned short alpha[(1 << (13))]; > } swbcht_GF; > > > typedef struct { > =A0swbcht_GF gf; > } swbcht_Handle; > > > static const swbcht_Polynomial _primPoly13; > > void _ComputeGFLookupTables (swbcht_Handle *bchH, int m) > { > =A0int i, j; > > =A0swbcht_GF *gf =3D &bchH->gf; > > =A0gf->m =3D m; > =A0gf->n =3D (1 << m) - 1; > > =A0gf->primPoly =3D &_primPoly13; > > =A0for (i =3D 0; i < gf->m; i++) { > =A0 =A0gf->alpha[gf->m] ^=3D (gf->primPoly->c[i] * gf->alpha[i]); > =A0} > } > > > The dump after CH - FRE looks like > > _ComputeGFLookupTables (struct swbcht_Handle * bchH, int m) > { > =A0int i; > =A0short unsigned int D.1241; > =A0short int D.1240; > =A0short int D.1239; > =A0short unsigned int D.1238; > =A0short unsigned int D.1237; > =A0short unsigned int D.1236; > =A0const int D.1235; > =A0const struct swbcht_Polynomial * D.1233; > =A0short int D.1232; > =A0short unsigned int D.1231; > =A0int D.1230; > =A0int D.1229; > =A0int D.1228; > > : > =A0bchH_2(D)->gf.m =3D m_4(D); > =A0D.1228_5 =3D 1 << m_4(D); > =A0D.1229_6 =3D D.1228_5 + -1; > =A0bchH_2(D)->gf.n =3D D.1229_6; > =A0bchH_2(D)->gf.primPoly =3D &_primPoly13; > =A0if (m_4(D) > 0) > =A0 =A0goto ; > =A0else > =A0 =A0goto ; > > : > =A0goto ; > > : > > : > =A0# i_35 =3D PHI <0(5), i_23(7)> > =A0D.1230_10 =3D bchH_2(D)->gf.m; > =A0D.1231_11 =3D bchH_2(D)->gf.alpha[D.1230_10]; > =A0D.1232_12 =3D (short int) D.1231_11; > =A0D.1233_13 =3D bchH_2(D)->gf.primPoly; > =A0D.1235_15 =3D D.1233_13->c[i_35]; > =A0D.1236_16 =3D (short unsigned int) D.1235_15; > =A0D.1237_18 =3D bchH_2(D)->gf.alpha[i_35]; > =A0D.1238_19 =3D D.1236_16 * D.1237_18; > =A0D.1239_20 =3D (short int) D.1238_19; > =A0D.1240_21 =3D D.1239_20 ^ D.1232_12; > =A0D.1241_22 =3D (short unsigned int) D.1240_21; > =A0bchH_2(D)->gf.alpha[D.1230_10] =3D D.1241_22; > =A0i_23 =3D i_35 + 1; > =A0D.1230_8 =3D bchH_2(D)->gf.m; > =A0if (i_23 < D.1230_8) > =A0 =A0goto ; > =A0else > =A0 =A0goto ; > > : > =A0goto ; > > : > > : > =A0return; > > } > > 1. Why does FRE miss eliminating expression bchH_2(D)->gf.primPoly in > bb 3 with &_primPoly13. This is normally the case if we ran FRE then > CH. > > Further PRE identifies bchH_2(D)->gf.primPoly as a partially redundant > expression and hoists it into predecessor bb 7 and we get > > : > =A0# i_35 =3D PHI <0(5), i_23(7)> > =A0# prephitmp.25_49 =3D PHI > =A0# prephitmp.27_51 =3D PHI <&_primPoly13(5), pretmp.26_50(7)> > =A0D.1230_10 =3D prephitmp.25_49; > =A0D.1231_11 =3D bchH_2(D)->gf.alpha[D.1230_10]; > =A0D.1232_12 =3D (short int) D.1231_11; > =A0D.1233_13 =3D prephitmp.27_51; > =A0D.1235_15 =3D D.1233_13->c[i_35]; > =A0D.1236_16 =3D (short unsigned int) D.1235_15; > =A0D.1237_18 =3D bchH_2(D)->gf.alpha[i_35]; > =A0D.1238_19 =3D D.1236_16 * D.1237_18; > =A0D.1239_20 =3D (short int) D.1238_19; > =A0D.1240_21 =3D D.1239_20 ^ D.1232_12; > =A0D.1241_22 =3D (short unsigned int) D.1240_21; > =A0bchH_2(D)->gf.alpha[D.1230_10] =3D D.1241_22; > =A0i_23 =3D i_35 + 1; > =A0D.1230_8 =3D bchH_2(D)->gf.m; > =A0if (D.1230_8 > i_23) > =A0 =A0goto ; > =A0else > =A0 =A0goto ; > > : > =A0pretmp.26_50 =3D bchH_2(D)->gf.primPoly; > =A0goto ; > > > Clearly prephitmp.27_51 will make a redundant induction variable. > Stepping through the insert_into_preds_of_block in tree-ssa-pre.c > I can see the value numbers for expression bchH_2(D)->gf.primPoly > available through bb 3 and through bb 2 are different. > > 2. Is this because alias analysis cannot determine bchH_2(D)->gf > has a unique target? You should move to GCC 4.5 - the alias-oracle in GCC 4.4 is too weak to discover all this and virtual operands are not helpful because these are all indirect accesses through pointers without points-to information. Richard. > > Many Thanks, > Rahul > >