From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18681 invoked by alias); 30 May 2005 17:26:24 -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 18395 invoked by uid 22791); 30 May 2005 17:26:16 -0000 Received: from eyesopen.com (HELO www.eyesopen.com) (208.41.78.163) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 30 May 2005 17:26:16 +0000 Received: from localhost (roger@localhost) by www.eyesopen.com (8.11.6/8.11.6) with ESMTP id j4UHQCm05357 for ; Mon, 30 May 2005 11:26:13 -0600 Date: Mon, 30 May 2005 18:38:00 -0000 From: Roger Sayle To: gcc@gcc.gnu.org Subject: Re: ifcvt.c question In-Reply-To: <200505292323.29675.stevenb@suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-05/txt/msg01631.txt.bz2 On Sun, 29 May 2005, Steven Bosscher wrote: > I don't understand what lines 2728 to 2741 are for. Could someone give > an example of when we can have a then_bb that has no successors, but > still ends in something that satisfies simplejump_p()? What kind of > strange indirect jump would that be? And shouldn't the check just use > computed_jump_p() if that is what it is looking for?? For the benefit of the list, I did some archeology to determine when this functionality was written and how it evolved to be so broken now. The mistake was a bug introduced by Michael Meisner back in 2000. The functionality was originally introduced by Richard Henderson to allow predication of then blocks that end in noreturn calls. 2000-05-31 Richard Henderson * ifcvt.c (merge_if_block): Be prepared for JOIN to have no remaining edges. (find_if_block): Allow THEN with no outgoing edges. * flow.c (merge_blocks_nomove): Remove a barrier not following a jump as well. posted: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01711.html Unfortunately, this exposed a bug in the d30v port that caused a regression in gcc.c-torture/execute/920428-1.c. As I suggested on IRC, this was a then-block that ended in a non-local goto, or more precisely an indirect jump. Michael tried to resolve this problem by excluding those blocks that ended in indirect jumps. His mistake was to assume that the way to eliminate indirect jumps was to limit this code to simple jumps! Doh! This inadvertantly disabled RTH's optimization, and the optimizations' code has been dead ever since. 2000-08-19 Michael Meissner * ifcvt.c (find_if_block): Do not assume that a THEN block has any instructions in it before checking for indirect jumps. * ifcvt.c (find_if_block): Do not consider a THEN block that ends in an indirect jump as a potential for conditional execution. * d30v.h (d30v_init_expanders): Don't declare here. * d30v-protos.h (d30v_init_expanders): Declare here with a valid prototype. posted: http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00736.html RTH should probably have added a testcase that checked whether this code was being optimized, so we'd know when it regressed. I also can't immediately see why a block that ends in an indirect jump shouldn't be considered for conditional execution, and he might well have been papering over another problem in the compiler (esp. the D30V backend). Of course now that support for D30V has been removed from CVS, it's difficult to diagnose whether this really was just a backend problem, and whether we should just return the code to a form similar to the one RTH originally contributed. I hope this answers your question. Roger --