From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1024 invoked by alias); 13 Sep 2004 15:05:44 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 998 invoked from network); 13 Sep 2004 15:05:42 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org with SMTP; 13 Sep 2004 15:05:42 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 29025) id 0695A4B44C0; Mon, 13 Sep 2004 17:05:42 +0200 (CEST) Date: Mon, 13 Sep 2004 15:49:00 -0000 From: Zdenek Dvorak To: Richard Guenther Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Peeling loops at tree level?, Lno branch merge patches ping Message-ID: <20040913150542.GA21101@atrey.karlin.mff.cuni.cz> References: <20040913144031.GA18970@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-SW-Source: 2004-09/txt/msg00773.txt.bz2 Hello, > > > > Do we (I suspect not) peel small loops at tree level yet? > > > Btw. lno from g++ (GCC) 3.5-tree-ssa-lno 20040630 (merged 20040612) > > > seems to do the trick: > > > > > > ;; Function int bar(constVector<3>&) (_Z3barRK6VectorILi3EE) > > > > > > int bar(constVector<3>&) (x) > > > { > > > [...] > > > : > > > return *&x->val[2] + x->val[1] + x->val[0] + res; > > > > > > } > > > > > > So I guess we'll get this feature during further merge of lno? > > > > indeed -- this will work once this lno branch merge patch > > > > http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00325.html > > > > is in and the optimization is enabled. > > Uh, this looks "old" - maybe you should ping for this merge? The patch of course is a bit out-of-date just now; only minor changes, like renaming uses of build_int_cst to build_int_cst_type and removing parts already merged with ivopts should be needed, however. > Current status of lno-merge seems a bit unclear at the moment. Patches #9, 10 and 11 (urls below) are waiting for review. Some optimizations that use parts of those patches need to be fully enabled once the patches are in. There are several followup patches, but they are just small ones (and we can survive without them if they are not accepted due to stage 3 restrictions). http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00300.html (part 9) http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00325.html (part 10) http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00404.html (part 11) The patches need to be reviewed in this order, since they depend on the previous ones. There are also several loop optimizer related patches submitted independently on the merge -- induction variables splitting in loop optimizer (newest version at http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01185.html) and removal of empty loops (http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01679.html). Zdenek