From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8491 invoked by alias); 8 Oct 2009 16:23:03 -0000 Received: (qmail 8480 invoked by uid 22791); 8 Oct 2009 16:23:02 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-vw0-f183.google.com (HELO mail-vw0-f183.google.com) (209.85.212.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Oct 2009 16:22:58 +0000 Received: by vws13 with SMTP id 13so3935vws.14 for ; Thu, 08 Oct 2009 09:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.69.90 with SMTP id y26mr2386221vci.51.1255018976457; Thu, 08 Oct 2009 09:22:56 -0700 (PDT) In-Reply-To: <20091008161802.GA30141@kam.mff.cuni.cz> References: <20091006065352.GB15626@kam.mff.cuni.cz> <20091006135624.GA18714@kam.mff.cuni.cz> <20091006150918.GA19277@kam.mff.cuni.cz> <20091008161802.GA30141@kam.mff.cuni.cz> Date: Thu, 08 Oct 2009 18:52:00 -0000 Message-ID: Subject: Re: Turning off unrolling to certain loops From: Jean Christophe Beyler To: Zdenek Dvorak Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00191.txt.bz2 Hi, > such an epilogue is needed when the # of iterations is not known in the > compile time; it should be fairly easy to modify the unrolling not to > emit it when it is not necessary, Agreed, that is why I was surprised to see this in my simple example. It seems to me that the whole unrolling process has been made to, on purpose, have this epilogue in place. In the case where the unrolling would be perfect (ie. there would be no epilogue), the calculation of the max bound of the unrolled version is always done to have this epilogue (if you have 4 iterations and ask to unroll twice, it will actually change the max bound to 3, therefore, having one iteration of the unrolled version and 2 iterations of the original...). I am currently looking at the code of tree_transform_and_unroll_loop to figure out how to change this and not have an epilogue in my cases. Jc