From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4522 invoked by alias); 19 Jan 2004 09:58:51 -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 4514 invoked from network); 19 Jan 2004 09:58:50 -0000 Received: from unknown (HELO Cantor.suse.de) (195.135.220.2) by sources.redhat.com with SMTP; 19 Jan 2004 09:58:50 -0000 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 8050E1A070DA; Mon, 19 Jan 2004 10:58:49 +0100 (CET) Received: by wotan.suse.de (Postfix, from userid 10510) id 56BFD10700; Mon, 19 Jan 2004 10:58:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 55520106B6; Mon, 19 Jan 2004 10:58:49 +0100 (CET) Date: Mon, 19 Jan 2004 09:58:00 -0000 From: Michael Matz To: Giovanni Bajo Cc: gcc@gcc.gnu.org Subject: Re: [new-ra] Development status? In-Reply-To: <22e301c3dd71$1875c480$34b82997@bagio> Message-ID: References: <22e301c3dd71$1875c480$34b82997@bagio> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-01/txt/msg01251.txt.bz2 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. 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. > How does it look like right now? Does it improve compile-time No. > or code generation? Sometimes. > On which platforms? Alpha, ppc. To a lesser extend x86 and amd64. > I would also like to ask why there is an active development branch for > new-ra. Sometimes I needed to touch other parts than ra*.c, which would have required full testing for mainline. Also a branch is more appropriate for experimental things, even if that functionality would be hidden by an command line arg, IMHO. > Can the latest version be merged to the 3.4 branch & mainline? Hmm. Let's say it this way, I don't want to have pre-reload in the current form in mainline. It simply adds too much cruft, and I fear if it lands in mainline it never will get cleaned up. But the allocator core is depending on pre-reload (unlike the one in currentl mainline). > Also, we never consider *any* new-ra bug as regressions since it's an > experimental switch for 3.4, so I guess changes can be committed there > freely, without the "regression-only" policy. Technically that's posible, but we also need to consider maintenability on our main branch. Ciao, Michael. P.S: Yes, I'm working on the above. Slowly, I admit.