From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15822 invoked by alias); 21 Dec 2002 23:46:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15790 invoked by uid 71); 21 Dec 2002 23:46:02 -0000 Date: Sat, 21 Dec 2002 15:46:00 -0000 Message-ID: <20021221234602.15788.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Jan Hubicka Subject: Re: optimization/8492: [3.3 regression] GCC spins forever compiling loop Reply-To: Jan Hubicka X-SW-Source: 2002-12/txt/msg01216.txt.bz2 List-Id: The following reply was made to PR optimization/8492; it has been noted by GNATS. From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , janis187@us.ibm.com, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, thorpej@shagadelic.org Subject: Re: optimization/8492: [3.3 regression] GCC spins forever compiling loop Date: Sun, 22 Dec 2002 00:43:50 +0100 > > I think deleting unreachable blocks is cheap enought to do in the case > > conditional jump was eliminated. > > Ok. But then the GCSE code needs to be (at least partially) re-initialized > because the number of basic blocks may change. I've attached a naive patch I > wrote some time ago: while fixing the PR (and doing some housekeeping work), > it introduces many regressions because of this problem. > > > Alternatively we may prevent first local cprop pass from modifying CFG. > > I don't know enough of the global organization of optimization passes to > comment. Will the optimizations missed at that point be caught elsewhere ? Yes, there are examples where removing the conditional would allow more PRE to happen, but I guess it is not that common. We already disable the transformation for global CPROP and in fact I am quite surprised that I didn't the same for local pass. I guess I just forgot about that. Honza > > -- > Eric Botcazou