* [new-ra] Development status?
@ 2004-01-18 3:13 Giovanni Bajo
2004-01-19 9:58 ` Michael Matz
0 siblings, 1 reply; 6+ messages in thread
From: Giovanni Bajo @ 2004-01-18 3:13 UTC (permalink / raw)
To: gcc
Hello,
what's the development status for new-ra? How does it look like right now? Does
it improve compile-time or code generation? On which platforms? This has been
also discussed several times on IRC with mixed results, so I would like to get
a complete status report for it. The point has been brought up in the tree-ssa
discussion as well.
I would also like to ask why there is an active development branch for new-ra.
We have a few bug reports in bugzilla which are against the mainline version
(-fnew-ra), which looks like to be outdated. Can the development be done on the
mainline directly? Can the latest version be merged to the 3.4 branch &
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.
Thanks!
Giovanni Bajo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [new-ra] Development status?
2004-01-18 3:13 [new-ra] Development status? Giovanni Bajo
@ 2004-01-19 9:58 ` Michael Matz
2004-01-20 16:35 ` Denis Chertykov
0 siblings, 1 reply; 6+ messages in thread
From: Michael Matz @ 2004-01-19 9:58 UTC (permalink / raw)
To: Giovanni Bajo; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [new-ra] Development status?
2004-01-19 9:58 ` Michael Matz
@ 2004-01-20 16:35 ` Denis Chertykov
2004-01-20 16:48 ` Michael Matz
0 siblings, 1 reply; 6+ messages in thread
From: Denis Chertykov @ 2004-01-20 16:35 UTC (permalink / raw)
To: Michael Matz; +Cc: Giovanni Bajo, gcc
Michael Matz <matz@suse.de> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [new-ra] Development status?
2004-01-20 16:35 ` Denis Chertykov
@ 2004-01-20 16:48 ` Michael Matz
2004-01-20 17:26 ` Denis Chertykov
0 siblings, 1 reply; 6+ messages in thread
From: Michael Matz @ 2004-01-20 16:48 UTC (permalink / raw)
To: Denis Chertykov; +Cc: Giovanni Bajo, gcc
Hi,
On Tue, 20 Jan 2004, Denis Chertykov wrote:
> 4. Then, allocator must have a support for register elimination.
Indeed, I forgot.
> Michael ! I have completed the patch which calculate register classes
> preferences as regclass (not as pre-reload).
Cool.
> Yes. I have converted regclass routines to work with webs.
I had hoped there would be something better than regclass on webs. *sniff*
> I was interested in comparision of results given by pre-reload based
> web_class and regclass based web_class.
They at least shouldn't be worse, I think, are they?
> Are you ready to look at patch and results ?
Yes, please.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [new-ra] Development status?
2004-01-20 16:48 ` Michael Matz
@ 2004-01-20 17:26 ` Denis Chertykov
2004-01-21 14:11 ` Michael Matz
0 siblings, 1 reply; 6+ messages in thread
From: Denis Chertykov @ 2004-01-20 17:26 UTC (permalink / raw)
To: Michael Matz; +Cc: Denis Chertykov, Giovanni Bajo, gcc
Michael Matz <matz@suse.de> writes:
> Hi,
>
> On Tue, 20 Jan 2004, Denis Chertykov wrote:
>
> > 4. Then, allocator must have a support for register elimination.
>
> Indeed, I forgot.
>
> > Michael ! I have completed the patch which calculate register classes
> > preferences as regclass (not as pre-reload).
>
> Cool.
>
> > Yes. I have converted regclass routines to work with webs.
>
> I had hoped there would be something better than regclass on
> webs. *sniff*
I'm too, but I can't imagine another way to got a quick comparison of
results pre-reload classes and regclass classes.
> > I was interested in comparision of results given by pre-reload based
> > web_class and regclass based web_class.
>
> They at least shouldn't be worse, I think, are they?
The results are *equal* !!! (for x86)
Exclude a few difficult cases.
> > Are you ready to look at patch and results ?
>
> Yes, please.
I can send it tomorrow morning. (I forgot the code at my work. The
mail will be from gazovik@overta.ru)
After you got the patch and seeing on results I would discuss the
problem of register classes in new-ra. Is this OK ?
Denis.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [new-ra] Development status?
2004-01-20 17:26 ` Denis Chertykov
@ 2004-01-21 14:11 ` Michael Matz
0 siblings, 0 replies; 6+ messages in thread
From: Michael Matz @ 2004-01-21 14:11 UTC (permalink / raw)
To: Denis Chertykov; +Cc: gcc
Hi,
On Tue, 20 Jan 2004, Denis Chertykov wrote:
> > > I was interested in comparision of results given by pre-reload based
> > > web_class and regclass based web_class.
> >
> > They at least shouldn't be worse, I think, are they?
>
> The results are *equal* !!! (for x86)
> Exclude a few difficult cases.
Hmm, but theoretically regclass can do much better than pre-reload (at the
expense for sometimes emitting some reloads later). The situation which
it handles better for instance is this:
There are register classes A, B and AB (union of A and B). Now suppose
there is and insns i1 (with two ops) and i2 (one op) having
such constraints:
i1 op0 "a,b" op1 "b,a"
i2 op0 "a"
and in the insn stream we have this:
i1(p0, p1)
i2(p1)
(p0 and p1 are pseudos, i.e. p0 is operand 0 of i1, and p1 is operand 1 of
i1 and operand 0 of i2).
Now pre-reload looks at each insn individually and selects one certain
alternative of it (the cheapest for some definition of cheap). Without
other means it would select alternative 0 for insn i1. Ergo p0 gets class
A and p1 class B.
Now i2 requires p1 to be class A, ergo we need some fixup code. Had
pre-reload selected the second alternative from the beginning it wouldn't
be needed. Sometimes there are even cases where selection of an
alternative should be deferred to even later.
regclass does better in this example. It would determine that the cost of
class A for p1 is less than class B.
> After you got the patch and seeing on results I would discuss the
> problem of register classes in new-ra. Is this OK ?
Yes.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-21 13:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-18 3:13 [new-ra] Development status? Giovanni Bajo
2004-01-19 9:58 ` Michael Matz
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
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).