From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1074 invoked by alias); 22 Sep 2004 20:46:22 -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 1064 invoked from network); 22 Sep 2004 20:46:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 22 Sep 2004 20:46:21 -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 i8MKkKQ6016854; Wed, 22 Sep 2004 16:46:20 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8MKkJr06398; Wed, 22 Sep 2004 16:46:20 -0400 Subject: Re: Bad code generated by inter-block scheduling From: Jeffrey A Law Reply-To: law@redhat.com To: Ulrich Weigand Cc: gcc@gcc.gnu.org In-Reply-To: <200409221834.UAA05495@faui1m.informatik.uni-erlangen.de> References: <200409221834.UAA05495@faui1m.informatik.uni-erlangen.de> Content-Type: text/plain Organization: Red Hat, Inc Message-Id: <1095885978.10950.532.camel@localhost.localdomain> Mime-Version: 1.0 Date: Wed, 22 Sep 2004 21:36:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg01313.txt.bz2 On Wed, 2004-09-22 at 12:34, Ulrich Weigand wrote: > > The task of distiguishing between interblock and speculative motion > is done using the notion of 'potential-split-edges', as computed > by compute_dom_prob_ps in sched-rgn.c. As I understand this code, > it looks for (generalized versions of) situations like this: > > [A] > / \ > [B] [C] > > If it finds such an edge A -> C, then a move from B to A would be > speculative, else it is a regular interblock motion. > > Now, in this particular case, we obviously *do* have exactly that > situation, with [A] = bb2, [B] = bb 1, [C] = exit block. > > However, the data structures available to compute_dom_prob_ps simply > do not contain the 'bb2 -> exit' edge in the first place! This is > because where the private structures in sched-rgn.c are built > (build_control_flow), all edges leading to the exit block are > completely ignored: > > nr_edges = 0; > for (i = 0; i < num_edges; i++) > { > edge e = INDEX_EDGE (edge_list, i); > > if (e->dest != EXIT_BLOCK_PTR > && e->src != ENTRY_BLOCK_PTR) > new_edge (e->src->index, e->dest->index); > } > > >From what I see from the revision histories, the behaviour apparently > has been the same since forever, so I don't know why this suddenly > shows up as a problem ... > > Simply adding entry/exit edges to the sched-rgn.c tables is not completely > trivial due to the negative block index numbers; several global arrays in > sched-rgn.c are indexed by block number. Any suggestions how to fix this? I've always hated the potential-split-edges nonsense in the interblock scheduling code. It seems to me what they're really after is just post-dominance. jeff