This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [new-ra] "#if DENIS"
- From: Denis Chertykov <denisc at overta dot ru>
- To: Michael Matz <matz at suse dot de>
- Cc: Denis Chertykov <denisc at overta dot ru>, gcc-patches at gcc dot gnu dot org
- Date: 15 Jul 2003 08:24:06 +0400
- Subject: Re: [new-ra] "#if DENIS"
- References: <Pine.LNX.4.44.0307140923140.26127-100000@wotan.suse.de>
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.