Re: [new-ra] Development status?

[Michael Matz <matz at suse dot de>]

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.