From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12135 invoked by alias); 30 Aug 2004 15:03:55 -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 12013 invoked from network); 30 Aug 2004 15:03:50 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 30 Aug 2004 15:03:50 -0000 Received: (qmail 31645 invoked from network); 30 Aug 2004 15:03:48 -0000 Received: from localhost (HELO ?192.168.0.105?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 30 Aug 2004 15:03:48 -0000 Message-ID: <413341D5.4030302@codesourcery.com> Date: Mon, 30 Aug 2004 15:11:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: Steven Bosscher CC: gcc@gcc.gnu.org, dberlin@dberlin.org Subject: Re: GCC 3.5 Status (2004-08-29) References: <4132641E.3030206@codesourcery.com> <200408300229.13652.stevenb@suse.de> <41327A88.5080903@codesourcery.com> <200408300934.13528.stevenb@suse.de> In-Reply-To: <200408300934.13528.stevenb@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg01493.txt.bz2 Steven Bosscher wrote: >On Monday 30 August 2004 02:53, Mark Mitchell wrote: > > >>>Hmm, let's argue. So you think 25-100% slowdown is justifyable despite >>>just about every project using GCC complaining about how GCC gets slower >>>with each release? >>> >>> >>Obviously, this is not ideal. However, we have few practical >>alternatives. I am not convinced that any further delay will get us >>better results. I do not see a broad committment to improving >>compile-time speed when optimizing: in fact, I got zero proposals from >>people planning to work specifically on that issue. >> >> > >It is funny that you say here that you got zero proposals, yet you >had a section in your mail: > > I had zero proposals that described among their benefits compile-time speed *when optimizing*. Perhaps Elliston's work will indeed help with that, but it wasn't called out seprately. I'm all for that work on lots of levels, which is why when we were talking about projects we could trade for aliasing, I suggested hanging on to that one. >Merging the LNO ivopts is another pass that could help win back speed >because it would allow us to kill the old loop optimizer (ie. loop.c >and unroll.c) and all the yuckie-ness that it causes, like >reconstructing the CFG, recomputing dominance, recomputing loop info, >etc. etc. All of that is expensive, and removing expensive things is >a good thing... > >Anyway, you are probably right that there appear to be few people >working *specifically* on speeding up the compiler. But many people >work on replacing expensive RTL optimizations with cheaper tree ones. > > Note that "merge LNO" is still on the plan, and I will be helping with that where I can. Is the ivopts stuff already there, or is it different? If it is already there, then perhaps you should work on getting the old loop optimizer ready to die, so that we can do as you suggest above. That might be a bigger, and easier to achieve, compile-time-when-optimizing improvement than Dan's stuff. >>Maintaining compilation speed was a precondition set by the SC for the >>tree-ssa merge. If that condition was not met, then perhaps the merge >>should not have been performed. The fact that it was probably indicates >>that people weren't too worried about these compile-time effects. >> >> > >We discussed compile time back then and it was believed that we could >win back enough speed before stage3 to get back to around GCC 3.4 speeds, >which is IMO a good start. After that, the Summit happened and suddenly >everyone was working on re-doing much of tree-ssa. We're also slower >now than we were at the merge point. >So yes, in retrospect perhaps the merge did come too early. > > It's water under the bridge in any case. But, now, we have to decide what to do next. >>I continue to think it will take at least another several months to >>really get to the point where tree-ssa is unambiguously better >>(consistently better code, consistently better compile-times, fewer >>bugs) than GCC 3.4. If people want to put GCC 3.5 off until next June, >>and SC approves, it's OK with me. >> >> > >If we can restrict ourselves to the features proposed in your list, >and work on just getting those items ready, releasing GCC 3.5 later >would IMHO be much better than rushing it out in January. > > I think it will be very hard to keep people from doing more stuff. The argument is going to be "my thing is ready, and tested, and seems to help something, so why can't it go in?" But each of those changes will introduce follow-on issues. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com