From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19441 invoked by alias); 8 Oct 2004 05:31:59 -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 19433 invoked from network); 8 Oct 2004 05:31:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Oct 2004 05:31:58 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i985VvNV016436; Fri, 8 Oct 2004 01:31:57 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i985Vvr06192; Fri, 8 Oct 2004 01:31:57 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i985VcTQ031232; Fri, 8 Oct 2004 01:31:38 -0400 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id i985VcCD031230; Fri, 8 Oct 2004 01:31:38 -0400 Date: Fri, 08 Oct 2004 07:05:00 -0000 From: Jakub Jelinek To: Kazu Hirata Cc: rth@redhat.com, dnovillo@redhat.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR tree-optimization/17724 Message-ID: <20041008053138.GQ31909@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <20041007200445.GN31909@devserv.devel.redhat.com> <20041007.181556.07457730.kazu@cs.umass.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041007.181556.07457730.kazu@cs.umass.edu> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-10/txt/msg00720.txt.bz2 On Thu, Oct 07, 2004 at 06:15:56PM -0400, Kazu Hirata wrote: > Hi Jakub, > > > The first patch calls free_dominance_info in cleanup_tree_cfg whenever > > delete_unreachable_blocks deleted some basic blocks. It should be safe, but > > might be expensive. > > I guess so. thread_jumps, which is called right after > delete_unreachable_blocks in cleanup_tree_cfg, tries to maintain the > dominator info, so if you are freeing it, you might want to remove the > code to maintain it in thread_jumps. Yeah, my preferred patch is 3 (recomputing some dominators in delete_unreachable_blocks). Possibly if that turns out to be too expensive when there are too many basic blocks as predecessors or successors of unreachable blocks (that aren't unreachable themselves), we could add later on some ceiling (the one 3rd of basic blocks below is completely arbitrary), e.g. if (nsuccs * 3 > n_basic_blocks) free_dominance_info (CDI_DOMINATORS); else for (i = 0; i < nsuccs; ++i) recompute one by one; Jakub