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"


Michael Matz <matz@suse.de> writes:

> 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.

Yes. This can introduces a few passes of allocation, but I havn't seen
more than two, and code quality will be higher than after reload pass.
Michael ! reload isn't so fast as you think. One reload pass can be
equal to allocation pass or even to two passes.

> 
> > 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).

What happened if such pseudos will be colored ?
To which color such pseudos will be colored ?
How will allocator insert colored pseudo to insn (reload again can
happened or special pass of allocation with pre-reload required) ?

Denis.


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