From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15500 invoked by alias); 20 Jan 2004 16:35:14 -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 15463 invoked from network); 20 Jan 2004 16:35:10 -0000 Received: from unknown (HELO overta.ru) (195.151.108.147) by sources.redhat.com with SMTP; 20 Jan 2004 16:35:10 -0000 Received: from [217.65.211.140] (HELO localhost.localdomain) by overta.ru (CommuniGate Pro SMTP 4.0.6) with ESMTP id 9542780; Tue, 20 Jan 2004 19:35:07 +0300 To: Michael Matz Cc: Giovanni Bajo , gcc@gcc.gnu.org Subject: Re: [new-ra] Development status? References: <22e301c3dd71$1875c480$34b82997@bagio> From: Denis Chertykov Date: Tue, 20 Jan 2004 16:35:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg01514.txt.bz2 Michael Matz writes: > Hi, > > On Sun, 18 Jan 2004, Giovanni Bajo wrote: > > > what's the development status for new-ra? > > There is one big patch outstanding waiting review (and mayby design > decisions), plus one smaller patch from Denis, which touches the remaining > big problem: > > 1. For reload to become reducable (at least on sufficiently sane, probably > on most platforms) we basically need to do something similar to > regclass. This means figuring out the correct (i.e. possbile) register > classes for each register reference. Due to GCCs design choosing a > class for one reference might influence the possible classes for other > references of the same register, or of other refs in the insn under > consideration. Implementing this optimally would mean finding some > minimal set of paths over a set of graphs (I'm not even yet sure how it > would have to be structured). I haven't tried this but I think it > would be too slow. > > Regclass.c does use some heuristics to find a good result, although > it's also not exactly fast. Currently we can either use the results > from regclass for new-ra, or use pre-reload to do that (which fixes the > choice of one certain alternative for an insn, before choosing > classes). Both result in suboptimal code, sometimes in horrible code. > > The above is something which needs to be implemented to make new-ra not > regress compared to current ra. > > 2. Then, before considering new-ra done, pre-reload.c needs to be heavily > massaged to not be an ugly clone of reload*.c . Cosmetic (it's more or > less a black box), but still important. > > 3. Then, performance issues. Some passes in new-ra are only candidates > for -O3 (or not even that), or have to be rewritten to be incremental. > Web splitting in particular, which would ideally be integrated into the > normal spilling process, which then also would mean we wouldn't have to > disable interference region spilling when using it. 4. Then, allocator must have a support for register elimination. > > The first numbered item above is ugly. I believe at least, I haven't even > starting implementing it, because I think it's so ugle ;-) I know that > this is a vicious circle. Michael ! I have completed the patch which calculate register classes preferences as regclass (not as pre-reload). Yes. I have converted regclass routines to work with webs. I was interested in comparision of results given by pre-reload based web_class and regclass based web_class. Are you ready to look at patch and results ? Denis.