From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27704 invoked by alias); 14 Dec 2010 21:06:09 -0000 Received: (qmail 27685 invoked by uid 22791); 14 Dec 2010 21:06:07 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD 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; Tue, 14 Dec 2010 21:05:56 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 29025) id AE8C49AC693; Tue, 14 Dec 2010 22:05:52 +0100 (CET) Date: Tue, 14 Dec 2010 21:55:00 -0000 From: Zdenek Dvorak To: "Fang, Changpeng" Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops Message-ID: <20101214210552.GA19633@kam.mff.cuni.cz> References: <20101214075629.GA10020@kam.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.18 (2008-05-17) 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/msg01132.txt.bz2 Hi, > >why not simply change the profile updating to correctly indicate that these loops do not roll? > >That way, all the optimizations would profit, not just those aware of the 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 vectorization, we know the expected # of iterations, based on their purpose; e.g., for loops inserted 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 disabling for small trip count > loops, significantly? Anything where we check whether we should optimize for speed or code size, Zdenek