From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16311 invoked by alias); 20 Oct 2004 13:27:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 15869 invoked from network); 20 Oct 2004 13:27:03 -0000 Received: from unknown (HELO x93.infopact.nl) (212.29.160.93) by sourceware.org with SMTP; 20 Oct 2004 13:27:03 -0000 Received: from steven.lr-s.tudelft.nl (70-90.ipact.nl [82.210.90.70]) by x93.infopact.nl (8.12.10/8.12.10) with ESMTP id i9KDR14I015833; Wed, 20 Oct 2004 15:27:01 +0200 From: Steven Bosscher Organization: SUSE Labs To: Andrew MacLeod , Jeff Law Subject: Re: Fix a tcb crash and a potential bug on mainline Date: Wed, 20 Oct 2004 13:32:00 -0000 User-Agent: KMail/1.5.4 Cc: gcc-patches , Diego Novillo References: <200410182303.52997.stevenb@suse.de> <1098227633.2915.166.camel@localhost.localdomain> <1098278085.5695.3886.camel@pain> In-Reply-To: <1098278085.5695.3886.camel@pain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410201527.38061.stevenb@suse.de> X-CanItPRO-Stream: NoScan X-Spam-Score: undef - spam-scanning disabled X-Canit-Stats-ID: 1181008 - 1e2897e87c1f X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004-10/txt/msg01720.txt.bz2 On Wednesday 20 October 2004 15:14, Andrew MacLeod wrote: > If I understand the problem properly, the fundamental problem here is > that a block becomes unreachable by removing all the incoming edges. PHI > arguments for those edges are removed as the edge is removed. When the > last edge is removed, the PHI node has no more arguments, and thus gets > deleted. None of the code in the dead block is removed until later when > delete_unreachable_blocks is called. Meanwhile, we end up pawing through > one or more stmts in the dead block which contains uses of the PHI > result. Correct. > I have a couple of questions. > > 1 - Why does cleanup_control_flow() ever look at a stmts inside an > unreachable block? Its seems rather, umm, unnecessary, for starters. Why > not just call delete_unreachable_blocks() as the *first* thing in > cfg_cleanup(). It doesn't look like its an expensive call... Well, it wouldn't help because the block is made unreachable by cleanup_control_flow(). What happens is that cleanup_control_flow() uses FOR_EACH_BB which walks BBs from index 0 to last_basic_block, so it sees BB 2 before BB 4. In the test case, cleaning up control flow out of BB 2 makes BB 4 unreachable. So calling delete_unreachable_blocks() before cleanup_control_flow() would not help in this case. Hence my patch to make cleanup_control_flow() ignore unreachable BBs. > 2 - The issue may also exist outside cleanup_control_flow, so why does > remove_phi_arg_num have to remove the PHI node when is removes the last > argument. That is what I believe to be the problem. Jeff thinks this is "the right thing" to do. > Why not allow the PHI node to exist with no arguments. That would work too, I guess. > > 2. When we release an SSA_NAME and PHI_NODE go and find all uses > > of the SSA_NAME and release them too. This is effectively an > > iterative DCE process. > > I am not very fond of this one :-) Especially since they are going to > be dealt with en-mass when you delete the block anyway. Exactly my feeling about this. Gr. Steven