Re: Reload work in progress

[Stephane Carrez <Stephane dot Carrez at worldnet dot fr>]

Hi!


Bernd Schmidt a écrit :
> 
> Every now and then, I'm working on a patch that changes several aspects of
> how reload works.  So far, most of the discussion has been on Redhat
> internal mailing lists; Jeff asked me to post a message here as well so
> that people know about it.  I'm not appending the patch in this mail, it's
> a bit too large (600K uncompressed).  If anyone is interested, I can send it
> privately - it's against a not too old CVS version of gcc.
> 

It's good news!

I'm interested to try on the 68hc11 port.  Since there is only 3 registers,
this is quite a good stressing environment for reload.

Can you send it to me with an aproximation date of your CVS version?

> [...]
>  - Reload inheritance is rewritten. It's structured as a pass within reload
>    and works with the lifetime data structures that were gathered.  It's
>    deliberately done so as to be not so intrusive on unrelated code - it's
>    a single block of code that could in theory be deleted without affecting
>    anything else.
>    It also works differently.  The old code runs in parallel with the actual
>    reloading; insns are processed in order, and we keep track of which hard
>    regs hold interesting values.  If it turns out we need one of these values
>    again, we'll reuse the hard reg.  The new code looks at all insns in an
>    extended basic block, gathering information about which insns reload
>    identical objects, and will then try to replace as many of these reloads
>    as possible with the same register.

For the 68HC11 I have a problem with that inheritance and the stack pointer.
The stack pointer cannot be used as an address register. It must be reloaded.
Then, the problem is that a push instruction does not have a PRE_DEC note
(this is a GCC global statement).  This means that the inheritance mechanism
does not detect that the stack pointer has changed (due to a push) and it
re-use a previous reload register.

How difficult would it be to fix that?

[I fixed that already in the current reload1.c]

> [...]
>
> Downsides of the patch are increased memory consumption, and most likely
> somewhat higher compile times as well.  I have not done any meaningful
> benchmarks yet, though.
> 
> Bernd

All this looks very promising,

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France