From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23773 invoked by alias); 31 Oct 2012 14:07:45 -0000 Received: (qmail 23736 invoked by uid 22791); 31 Oct 2012 14:07:44 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Oct 2012 14:07:32 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 67CB6A5208; Wed, 31 Oct 2012 15:07:31 +0100 (CET) Date: Wed, 31 Oct 2012 14:07:00 -0000 From: Richard Biener To: Jan Hubicka Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org Subject: Re: Non-dominating loop bounds in tree-ssa-loop-niter 3/4 In-Reply-To: <20121031140516.GD15866@kam.mff.cuni.cz> Message-ID: References: <20121031103949.GD19020@kam.mff.cuni.cz> <20121031120359.GA13132@kam.mff.cuni.cz> <20121031122234.GA15866@kam.mff.cuni.cz> <20121031123408.GH1752@tucnak.redhat.com> <20121031140516.GD15866@kam.mff.cuni.cz> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2012-10/txt/msg02939.txt.bz2 On Wed, 31 Oct 2012, Jan Hubicka wrote: > > On Wed, Oct 31, 2012 at 01:30:02PM +0100, Richard Biener wrote: > > > On Wed, 31 Oct 2012, Jan Hubicka wrote: > > > > > unroll you mean. Because unrolling mutates the CFG too much. > > > > > Well - it was just a starting point, populating -Og with as little > > > > > as possible and 100% profitable transforms (in both debug and speed > > > > > metric). In late opts we only do (early opt queue is shared): > > > > > > > > Well, and what about early cunrolli? > > > > > > It's not there (and I would disable it for -Og). > > > > Generally, most of the loop transforms are undesirable for -Og. > > Hmm, do we have some guidelines what is and is not desirable for -Og? > Unrolling/header copying being code duplicating optimization do not really > throw away any info by themself only require debugger to understand that some > code may get duplicated, but it is not different from i.e. inlining. Of course > the subsequent const prop will make it impossible to write into the iv > variable, but do we want to support reliable writting into user vars (i.e. > disable cprop on user vars) at -Og? No, we don't support reliable writing. We should first sort out issues with the current passes and debug info, look at compile-time and runtime performance and then add new passes. Richard.