From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13962 invoked by alias); 14 Dec 2004 00:13:21 -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 13871 invoked from network); 14 Dec 2004 00:13:09 -0000 Received: from unknown (HELO mail.cs.umass.edu) (128.119.243.168) by sourceware.org with SMTP; 14 Dec 2004 00:13:09 -0000 Received: from localhost (IDENT:O8l1CRG8SKhUg8kJ+mkHyQjAf9TMIu0S@loki.cs.umass.edu [128.119.243.168]) by mail.cs.umass.edu (8.12.11/8.12.5) with ESMTP id iBE0D9uY022053; Mon, 13 Dec 2004 19:13:09 -0500 Date: Tue, 14 Dec 2004 00:13:00 -0000 Message-Id: <20041213.191304.79427217.kazu@cs.umass.edu> To: law@redhat.com Cc: gcc@gcc.gnu.org, stevenb@suse.de, dvorakz@suse.cz Subject: Re: Good news about increased jump threading from my PHI merge patch From: Kazu Hirata In-Reply-To: <1102978556.14666.147.camel@localhost.localdomain> References: <1102955877.14666.94.camel@localhost.localdomain> <20041213.125724.34765950.kazu@cs.umass.edu> <1102978556.14666.147.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00477.txt.bz2 Hi Jeff, > > I think my pass > > basically requires DCE. We clean up CFG before entering SSA, so we > > shouldn't have any PHI merge opportunity unless some dead code between > > two PHI nodes are removed. > Which almost makes me wonder if removing forwarder blocks is better > off as its own pass. That's what I am doing for PHI merge. > We would schedule it to run after the DCE/DSE. We would also call > it from cleanup_tree_cfg if and only if we were able to determine > the result of a COND_EXPR_COND or SWITCH_COND. But we have more ways to create forwarder blocks than just DCE and DSE. split_edge creates forwarder blocks. So does ch. I instrumented cleanup_tree_cfg and printed the current pass name whenever forwarder blocks are removed while compiling cc1-i files. Here is the number of times cleanup_forwarder_blocks did some work. 5034 dce 5024 loopdone 2352 ch 1903 cddce 1477 final_cleanup 1449 cfg 1373 dom 32 tailr 28 ccp 3 phiopt Passes that call cleanup_tree_cfg (either directly or via TODO_cleanup_cfg) are ccp, dom, dce, cddce, loopdone, ch, phiopt, tailr, tailc, pre, and final_cleanup. The only pass that does not appear in the stats above is tailc. PRE does not appear either but that's because abnormal edges don't appear in GCC source code. Kazu Hirata