From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14686 invoked by alias); 16 May 2002 15:05:11 -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 14649 invoked from network); 16 May 2002 15:05:09 -0000 Received: from unknown (HELO www.dberlin.org) (151.203.29.129) by sources.redhat.com with SMTP; 16 May 2002 15:05:09 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by www.dberlin.org (Postfix) with ESMTP id E44774D05EFF; Thu, 16 May 2002 11:05:08 -0400 (EDT) Date: Thu, 16 May 2002 08:31:00 -0000 From: Daniel Berlin To: Robert Dewar Cc: mark@codesourcery.com, , , , , Subject: Re: GCSE store motion In-Reply-To: <20020516114838.949B6F28C9@nile.gnat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-05/txt/msg01304.txt.bz2 On Thu, 16 May 2002, Robert Dewar wrote: > > That means we shouldn't be spending much time trying to do software > > loop pipelining when compiling GCC, so the optimization shouldn't > > make compiling the compiler significantly slower. > > I don't see how you conclude this. You have to do the analysis on every > loop. Not really. Intel's compiler immediately discounts loops with calls in them. > There will definitely be loops in GCC where the optimization is > possible, there will be loops where it is not. I would expect the > compiler to spend quite a bit of time trying to improve code for > loops in GCC. What I am saying is that I doubt that the overall > effect will be that benficial for GCC. >