From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10337 invoked by alias); 21 Sep 2004 17:59:43 -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 10326 invoked from network); 21 Sep 2004 17:59:42 -0000 Received: from unknown (HELO dberlin.org) (68.164.203.246) by sourceware.org with SMTP; 21 Sep 2004 17:59:42 -0000 Received: from [129.34.20.23] (HELO [9.2.217.169]) by dberlin.org (CommuniGate Pro SMTP 4.2.1) with ESMTP id 7331888; Tue, 21 Sep 2004 13:59:42 -0400 In-Reply-To: <41505056.5060900@redhat.com> References: <41505056.5060900@redhat.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <039DC04D-0BF8-11D9-9263-000D93B1B044@dberlin.org> Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org, tm_gccmail@kloo.net, Steven Bosscher From: Daniel Berlin Subject: Re: Interesting paper from Perdue Date: Tue, 21 Sep 2004 18:39:00 -0000 To: Vladimir Makarov X-SW-Source: 2004-09/txt/msg01247.txt.bz2 On Sep 21, 2004, at 12:01 PM, Vladimir Makarov wrote: > tm_gccmail@kloo.net wrote: > >> On Mon, 20 Sep 2004, Steven Bosscher wrote: >> >> >>> I don't know if anyone has ever seen/read/mentioned this paper >>> before, I might have missed it. Otherwise, interesting reading: >>> https://engineering.purdue.edu/ECE/Research/TR/2004pdfs/TR-ECE-04 >>> -01.pdf >>> >>> Gr. >>> Steven >>> >> >> I'll digress and rant a bit; apologizes in advance. >> >> This is just the tip of the iceberg, really. There are many other >> instances where various optimizations are improved in isolation and >> degrade performance because they don't consider the effects on the >> other >> optimization passes. >> >> > I think the approach mentioned in article has a merit for any > compiler. Any optimized compiler is bunch of pass because of > complexity task. Many passes are trying to solve subproblem not taking > other passes into account. It creates unpredictable compiler > behaviour for given program when an optimization is on or off. > >> ...and the register allocator doesn't handle the increased register >> pressure well, so the net result is very little improvement. >> >> We really spend some time improving the foundation of GCC instead of >> piling more and more optimizations on top of it. >> >> > I agree with this. Gcc probably is a compiler with very upredictabe > behaviour because inadequate register allocator/scheduler. But > writing a good register allocator is not easy task in gcc because of > very rich register file model and a lot of machine-dependent macros > used by gcc ports. We have a register file model so rich that no single architecture is described well enough to get good results. There is something ironic about this. :) > The colour-based register allocator project is an example of this. I > know about this because I worked on register allocator improvements > and I am still working on it. I think the key component is reload > pass. Tasks solved by reload should be combined with the register > allocator. We should rid off reload. But it is an eneormous task. Yes, which is one of a myriad of reasons new-ra never succeeded. The goals were too ambitious Getting rid of reload is a project all itself. > > Vlad > >