From: Michael Matz <matz@suse.de>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: gcc@gcc.gnu.org
Subject: Re: [new-ra] Development status?
Date: Mon, 19 Jan 2004 09:58:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.58.0401191023350.3429@wotan.suse.de> (raw)
In-Reply-To: <22e301c3dd71$1875c480$34b82997@bagio>
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.
next prev parent reply other threads:[~2004-01-19 9:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-18 3:13 Giovanni Bajo
2004-01-19 9:58 ` Michael Matz [this message]
2004-01-20 16:35 ` Denis Chertykov
2004-01-20 16:48 ` Michael Matz
2004-01-20 17:26 ` Denis Chertykov
2004-01-21 14:11 ` Michael Matz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0401191023350.3429@wotan.suse.de \
--to=matz@suse.de \
--cc=gcc@gcc.gnu.org \
--cc=giovannibajo@libero.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).