From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23709 invoked by alias); 15 Oct 2009 16:12:00 -0000 Received: (qmail 23700 invoked by uid 22791); 15 Oct 2009 16:11:59 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mms1.broadcom.com (HELO mms1.broadcom.com) (216.31.210.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 16:11:55 +0000 Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 15 Oct 2009 09:11:38 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 15 Oct 2009 09:11:38 -0700 From: "Bingfeng Mei" To: "Jean Christophe Beyler" , "Zdenek Dvorak" cc: "gcc@gcc.gnu.org" Date: Thu, 15 Oct 2009 16:27:00 -0000 Subject: RE: Turning off unrolling to certain loops Message-ID: <7FB04A5C213E9943A72EE127DB74F0AD93CCBE4BBC@SJEXCHCCR02.corp.ad.broadcom.com> References: <20091006150918.GA19277@kam.mff.cuni.cz> <20091008161802.GA30141@kam.mff.cuni.cz> <7FB04A5C213E9943A72EE127DB74F0AD93CCBE4AD6@SJEXCHCCR02.corp.ad.broadcom.com> <20091015100020.GA21790@kam.mff.cuni.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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-10/txt/msg00342.txt.bz2 Jc, How did you implement #pragma unroll? I checked other compilers. The pragma should govern the next immediate loop. It took me a while to=20 find a not-so-elegant way to do that. I also implemented #pragma ivdep. These information are supposed to be passed through both tree and RTL levels and suvive all GCC optimization. I still have problem in handling combination of unroll and ivdep. Bingfeng > -----Original Message----- > From: fearyourself@gmail.com [mailto:fearyourself@gmail.com]=20 > On Behalf Of Jean Christophe Beyler > Sent: 15 October 2009 16:34 > To: Zdenek Dvorak > Cc: Bingfeng Mei; gcc@gcc.gnu.org > Subject: Re: Turning off unrolling to certain loops >=20 > You are entirely correct, I hadn't thought that through enough. >=20 > So I backtracked and have just merged what Bingfeng Mei has done with > your code and have now a corrected version of the loop unrolling. >=20 > What I did was directly modified tree_unroll_loop to handle the case > of a perfect unroll or not internally and then used something similar > to what you had done around that. I added what I think is needed to > stop unrolling of those loops in later passes. >=20 > I'll be starting my tests but I can port it to 4.5 if you are > interested to see what I did. > Jc >=20 > On Thu, Oct 15, 2009 at 6:00 AM, Zdenek Dvorak=20 > wrote: > > Hi, > > > >> I faced a similar issue a while ago. I filed a bug report > >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D36712) In the end, > >> I implemented a simple tree-level unrolling pass in our port > >> which uses all the existing infrastructure. It works quite well for > >> our purpose, but I hesitated to submit the patch because=20 > it contains > >> our not-very-elegannt #prgama unroll implementation. > > > > could you please do so anyway? =A0Even if there are some=20 > issues with the > > #prgama unroll implementation, it could serve as a basis of a usable > > patch. > > > >> /* Perfect unrolling of a loop */ > >> static void tree_unroll_perfect_loop (struct loop *loop,=20 > unsigned factor, > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 edge exit) > >> { > >> ... > >> } > >> > >> > >> > >> /* Go through all the loops: > >> =A0 =A0 =A01. Determine unrolling factor > >> =A0 =A0 =A02. Unroll loops in different conditions > >> =A0 =A0 =A0 =A0 -- perfect loop: no extra copy of original loop > >> =A0 =A0 =A0 =A0 -- other loops: the original version of loops to=20 > execute the remaining iterations > >> */ > >> static unsigned int rest_of_tree_unroll (void) > >> { > > ... > >> =A0 =A0 =A0 =A0tree niters =3D number_of_exit_cond_executions(loop); > >> > >> =A0 =A0 =A0 =A0bool perfect_unrolling =3D false; > >> =A0 =A0 =A0 =A0if(niters !=3D NULL_TREE && niters!=3D chrec_dont_know= =20 > && TREE_CODE(niters) =3D=3D INTEGER_CST){ > >> =A0 =A0 =A0 =A0 =A0int num_iters =3D tree_low_cst(niters, 1); > >> =A0 =A0 =A0 =A0 =A0if((num_iters % unroll_factor) =3D=3D 0) > >> =A0 =A0 =A0 =A0 =A0 =A0perfect_unrolling =3D true; > >> =A0 =A0 =A0 =A0} > >> > >> =A0 =A0 =A0 =A0/* If no. of iterations can be divided by unrolling=20 > factor, we have perfect unrolling */ > >> =A0 =A0 =A0 =A0if(perfect_unrolling){ > >> =A0 =A0 =A0 =A0 =A0tree_unroll_perfect_loop(loop, unroll_factor,=20 > single_dom_exit(loop)); > >> =A0 =A0 =A0 =A0} > >> =A0 =A0 =A0 =A0else{ > >> =A0 =A0 =A0 =A0 =A0tree_unroll_loop (loop, unroll_factor,=20 > single_dom_exit (loop), &desc); > >> =A0 =A0 =A0 =A0} > > > > It would be better to move this test to tree_unroll_loop, and not > > duplicate its code in tree_unroll_perfect_loop. > > > > Zdenek > > >=20 >=20