Re: [new-ra] Development status?

[Denis Chertykov <denisc@overta.ru>]

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.