From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3799 invoked by alias); 15 Dec 2010 02:35:43 -0000 Received: (qmail 3703 invoked by uid 22791); 15 Dec 2010 02:35:43 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iw0-f175.google.com (HELO mail-iw0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Dec 2010 02:35:38 +0000 Received: by iwn8 with SMTP id 8so1534074iwn.20 for ; Tue, 14 Dec 2010 18:35:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.191.4 with SMTP id dk4mr4246728ibb.31.1292380536965; Tue, 14 Dec 2010 18:35:36 -0800 (PST) Received: by 10.231.15.2 with HTTP; Tue, 14 Dec 2010 18:35:36 -0800 (PST) In-Reply-To: <20101214210552.GA19633@kam.mff.cuni.cz> References: <20101214075629.GA10020@kam.mff.cuni.cz> <20101214210552.GA19633@kam.mff.cuni.cz> Date: Wed, 15 Dec 2010 06:16:00 -0000 Message-ID: Subject: Re: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops From: Richard Guenther To: Zdenek Dvorak Cc: "Fang, Changpeng" , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg01168.txt.bz2 On Tue, Dec 14, 2010 at 10:05 PM, Zdenek Dvorak w= rote: > Hi, > >> =A0>why not simply change the profile updating to correctly indicate tha= t these loops do not roll? >> >That way, all the optimizations would profit, not just those aware of t= he new bb flag, >> >> Maybe my understanding is not correct. But I feel not comfortable using = profile of trip count >> to guard loop optimizations. > > it is already used that way; i.e., you do not need to change anything in = the optimizations, just > make sure that the edge probabilities are sensible. > >> For a given program, different data sizes will result in quite different >> loop trip counts. > > That should not be the case -- for the pre/post loops generated in vector= ization, we know the > expected # of iterations, based on their purpose; e.g., for loops inserte= d so that the # of iterarations > is divisible by 4, we know that the loop will iterate at most three times= (and probably less), etc. > >> By the way, what optimizations else do you think will benefit from disab= ling for small trip count >> loops, significantly? > > Anything where we check whether we should optimize for speed or code size, I agree with Zdenek (without having looked at the patch sofar). Richard. > Zdenek >