From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-157289-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2589 invoked by alias); 15 Oct 2009 10:00:33 -0000
Received: (qmail 2570 invoked by uid 22791); 15 Oct 2009 10:00:29 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from nikam-dmz.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 10:00:25 +0000
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 29025) 	id E833B1535CF; Thu, 15 Oct 2009 12:00:20 +0200 (CEST)
Date: Thu, 15 Oct 2009 14:41:00 -0000
From: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>
To: Bingfeng Mei <bmei@broadcom.com>
Cc: Jean Christophe Beyler <jean.christophe.beyler@gmail.com>, 	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Turning off unrolling to certain loops
Message-ID: <20091015100020.GA21790@kam.mff.cuni.cz>
References: <c568a2600910060634v4d78ad75x463d7e20edeea0f4@mail.gmail.com> <20091006135624.GA18714@kam.mff.cuni.cz> <c568a2600910060756m96adf86mb1507c6717fdfdb6@mail.gmail.com> <20091006150918.GA19277@kam.mff.cuni.cz> <c568a2600910060828l24ec5ecct926eb2624a1d2157@mail.gmail.com> <c568a2600910080722k794552fvbde46fed95601b21@mail.gmail.com> <20091008161802.GA30141@kam.mff.cuni.cz> <c568a2600910080922n7f5496bfged5d9473ca04200b@mail.gmail.com> <c568a2600910141129i75b2fa2bre4aff548ed376905@mail.gmail.com> <7FB04A5C213E9943A72EE127DB74F0AD93CCBE4AD6@SJEXCHCCR02.corp.ad.broadcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7FB04A5C213E9943A72EE127DB74F0AD93CCBE4AD6@SJEXCHCCR02.corp.ad.broadcom.com>
User-Agent: Mutt/1.5.9i
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-10/txt/msg00335.txt.bz2

Hi,

> I faced a similar issue a while ago. I filed a bug report 
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) 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 it contains
> our not-very-elegannt #prgama unroll implementation. 

could you please do so anyway?  Even if there are some 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, unsigned factor,
> 		  edge exit)
> {
> ...
> }
> 
> 
>                   
> /* Go through all the loops: 
>      1. Determine unrolling factor
>      2. Unroll loops in different conditions
>         -- perfect loop: no extra copy of original loop
>         -- other loops: the original version of loops to execute the remaining iterations
> */        
> static unsigned int rest_of_tree_unroll (void)
> {
...
>        tree niters = number_of_exit_cond_executions(loop);
>        
>        bool perfect_unrolling = false;
>        if(niters != NULL_TREE && niters!= chrec_dont_know && TREE_CODE(niters) == INTEGER_CST){
>          int num_iters = tree_low_cst(niters, 1);
>          if((num_iters % unroll_factor) == 0)
>            perfect_unrolling = true;
>        }
>        
>        /* If no. of iterations can be divided by unrolling factor, we have perfect unrolling */
>        if(perfect_unrolling){
>          tree_unroll_perfect_loop(loop, unroll_factor, single_dom_exit(loop));
>        }
>        else{
>          tree_unroll_loop (loop, unroll_factor, single_dom_exit (loop), &desc);
>        }

It would be better to move this test to tree_unroll_loop, and not
duplicate its code in tree_unroll_perfect_loop.

Zdenek