From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 745 invoked by alias); 29 May 2007 01:03:03 -0000 Received: (qmail 737 invoked by uid 22791); 29 May 2007 01:03:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail3.panix.com (HELO mail3.panix.com) (166.84.1.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 May 2007 01:03:00 +0000 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id 3492513A98E; Mon, 28 May 2007 21:02:58 -0400 (EDT) Received: from [192.168.1.60] (pool-70-104-128-175.nycmny.fios.verizon.net [70.104.128.175]) by mailspool2.panix.com (Postfix) with ESMTP id EFA97440080; Mon, 28 May 2007 21:02:57 -0400 (EDT) Message-ID: <465B7BC1.8090208@naturalbridge.com> Date: Tue, 29 May 2007 01:16:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: Mark Mitchell CC: Bernd Schmidt , gcc-patches , Steven Bosscher , "Park, Seongbae" , "Bonzini, Paolo" , Serge Belyshev , richard.earnshaw@arm.com, echristo@apple.com, "Pinski, Andrew" , "Weigand, Ulrich" , Ian Lance Taylor , "Edelsohn, David" , "Berlin, Daniel" Subject: Re: dataflow branch merging plans. References: <46543F49.8060104@naturalbridge.com> <46557380.9060105@t-online.de> <4655EF12.6060605@naturalbridge.com> <4656AFFD.1040605@t-online.de> <465B3740.5060906@codesourcery.com> In-Reply-To: <465B3740.5060906@codesourcery.com> 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: 2007-05/txt/msg01937.txt.bz2 Mark Mitchell wrote: > Bernd Schmidt wrote: > > >> Still, 6% compile time regression on several targets and typically a >> (very small) regression in SPEC scores - am I the only one who's not >> impressed? We don't normally accept patches with these kinds of >> results, and I don't see why we should make an exception here. >> > > If Kenny commits to continuing to work on these issues, I think we > should trust him. We've been around on this issue before, and we all > need to bear in mind that the point of the dataflow branch is not to > have better code immediately, but to have infrastructure that helps us > get better code. So, as long as we're not significantly moving > backwards on generated code performance, I'm not worried about that > aspect. > > As for compilation time, yes, that's a concern. However, I think it's > reasonable to move forward, as long as Kenny commits to continuing to > work on this. That might include, for example, converting more passes > to use the new machinery, so as to get more benefit from it. > > Kenny, I think that what I would like to hear is that, roughly in order > of urgency: > > (1) You will promptly address any regressions introduced by the merge > for all targets, provided you get a decent test-case. > > (2) You will continue to work on integrating the new dataflow machinery > into the compiler, to help with the compile-time performance and to help > get better results out of the passes that roll their own dataflow stuff. > > (3) You will promptly fix up coding standards issues that people point out. > > That's what I understand you to be saying, and on that basis, I think > you should proceed with the merge. If there are objections from other > global write maintainers in the next 48 hours, then let's try to get > consensus before you go ahead. However, I would hope that we can all > agree to let Kenny move forward with this important piece of infrastructure. > > Thanks, > > Mark, We will continue to work on these issues after the merge. My priorities have generally been (3) (1) (2). The reason that I put (3) in front is that these generally do not take any time in terms of investigation or testing, so it is easiest to just do them and move on. I put (1) next because these problem generally effect peoples ability to work on gcc and it is unreasonable that this branch should hinder people in their work. However, the reports on the rest of the ports are coming in generally good. The sh, and arm are regression free. The mips may have one exception handling failure, but Eric seems to have hit a similar problem to Ulrich, in that the trunk has destabilized since our last merge and just checking regression against the latest mainline is pretty iffy because of this instability. The performance issues will then be address, first with ia-64 since that has been the odd man out. Both seonbae and i have access to ia-64's so access is not a problem. Kenny