This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [new-ra] "#if DENIS"


Hi,

On 10 Jul 2003, Denis Chertykov wrote:

> Generally yes. Main idea of delayed remat. was: try to colorize
> spilled web before real spilling(remat.).

Yep.  And this only makes sense if it either comes for free (i.e. doesn't
add more rounds of coloring), or if the web didn't get a color for other
reasons than just high pressure.

> Really I'm prefer splitting here not a spilling.
> (Too similar spelling of different things spilling and splitting.)

The problem with naming it splitting is that there is another spilling
technique called web splitting, which now also is implemented, where webs
are split around other webs.  The main difference is, that for web
splitting the necessary instructions are not added at particular uses or
defs of the to-be-split web, but at references of the web it's split
around.  This really looks much more than splitting than your method.
That one merely chooses a different backing store, but otherwise is normal
spilling (as far as the methods for adding the spill code are concerned).

Anyway, that's just names.  I think we agree on the basic technique.

> >     1) it's spilled because unfortunate limited class compared to the
> >        widest possible useful class
> >        --> spill them to normal new pseudos, which then get that wider
>
> As I understand you in this phase you will use splitting not a
> spilling. Is this right ?

What you called splitting, yes.  I.e. using a normal new pseudo reg as
backing store.

> > Additionally on architectures with limited addressing modi we have to
> > allocate real stack slots for all stack pseudos, or backing pseudos which
> > didn't get a color (i.e. an_unusable_color).  Currently this is done
> > unconditionally.
>
> I'm agree with you.
> Are you sure that all stack slots which being incorporated to insns
> will be accepted by constraints checking ? (even on ix86)
> I'm not. Reload will be required.

If an insn accepts any memory operand, it will accept "(fp + ofs)" with no
limitation on ofs.  Even if this were not the case and seldomly a reload
for some instructions would be necessary I still would take that, because
by defering _all_ stack allocations to the end you have much higher
probability of sharing spill slots.  Also the longer stack allocation is
deferred the higher the probability of a stack pseudo eventually getting a
color due to secondary effects.

>   if (/* !spill_p && */ subst_to_stack_p ())
>     /* If you uncomment the SPILL_P usage then you will have a calls to
>        assign_stack_slots only at end of allocation process.
>        See to the caller of actual_spill.  */
>
> IMHO: Better to have the one call to assign_stack_slots and may be
> one or two (no more than two, I believe) passes of allocation than one
> reload pass.

If it's only one round overall I would agree.  The problem is, that in the
worst case this introduces an additional round _per_ original round.  One
round something is spilled, the next round this does the final spilling
for things which couldn't get colored.  Next round again normal spilling,
after that another one for final spilling, and so on.

> Also, I can't understand why you use validate_change not ra_validate_change.

I made the appropriate changes to recog.c.  While the new ra is running
spill pseudos are recognized as memory expressions (as offseted from the
frame or stack pointer, but with the real offset unknown).


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]