From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26797 invoked by alias); 9 Feb 2008 01:26:37 -0000 Received: (qmail 26718 invoked by uid 22791); 9 Feb 2008 01:26:36 -0000 X-Spam-Check-By: sourceware.org Received: from mail1.panix.com (HELO mail1.panix.com) (166.84.1.72) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 09 Feb 2008 01:26:10 +0000 Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id 5006E2940D; Fri, 8 Feb 2008 20:26:08 -0500 (EST) Received: from [192.168.1.10] (pool-72-89-83-51.nycmny.fios.verizon.net [72.89.83.51]) by mailbackend.panix.com (Postfix) with ESMTP id 429C3123C7; Fri, 8 Feb 2008 20:26:08 -0500 (EST) Message-ID: <47AD0130.8040304@naturalbridge.com> Date: Sat, 09 Feb 2008 03:40:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 2.0.0.9 (X11/20070801) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Seongbae_Park_=28=3F=3F=3F=2C_=3F=3F=3F=29=22?= CC: gcc-patches , "Bonzini, Paolo" Subject: Re: [PATCH] proper dataflow block visitation order References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-02/txt/msg00271.txt.bz2 Seongbae Park (???, ???) wrote: > This is an embarrassing mistake on my part that I only noticed this week, > where we were using wrong block visit orders for dataflow analysis > i.e. for forward problem, reverse postorder is the best known > but we have been using postorder of inverted graph, > and for backward problem, we should have used reverse postorder of > inverted graph > but we've been using postorder (of non-inverted). > > Two mistakes (of not reversing the postorder, and using wrong graph direction) > canceled each other somewhat which made this mistake not noticeable > for this long. > The following patch reduces the total number of block visits during > dataflow by about 4% > building cc1 on i686, and it also reduces the block visits for the > testcases in PR34400. > > While this is an overall win, there are cases where this patch increases > the number of visits - I'll have to look at them further later, > but clearly this is the right thing to do for now. > > Bootstrapped on i686 with c/c++ and no regression. > While this is not exactly a regression, > I'd like to commit this to 4.3 - > as it's a fairly safe change (famous last word :). > On the other hand, this is only a compile time fix > and not a high-impact one at that, > so I don't have very strong opinion on this. > > Seongbae > > > 2008-02-08 Seongbae Park > > * df-core.c (reverse_array, df_compute_postoder): New functions. > (rest_of_handle_df_initialize): Refactored > to call df_compute_postorder. > (df_analyze): Refactored to call df_compute_postorder. > Pass proper ordering for forward and backward problems. > (df_get_postorder): Return the correct block ordering. > (df_compact_blocks): Call df_compute_postorder. > Does this effect the issues that were raised in pr34400? this is clearly ok for 4.4. At this point mark mitchel has to approve it for 4.3 and i assume the answer is no. kenny