This is the mail archive of the
mailing list for the GCC project.
Re: Register Allocator query.
- From: Denis Chertykov <denisc at overta dot ru>
- To: Leon Taylor <leon_taylor_007 at yahoo dot co dot in>
- Cc: Denis Chertykov <denisc at overta dot ru>, Michael Matz <matz at suse dot de>, gcc at gcc dot gnu dot org
- Date: 24 Nov 2002 20:17:49 +0300
- Subject: Re: Register Allocator query.
- References: <email@example.com>
Leon Taylor <firstname.lastname@example.org> writes:
> Denis Chertykov <email@example.com> wrote:
> > > > A related query. In a comment in "web" structure
> > > > in gcc/ra.h
> > > > /* While spilling this is the rtx of the home of
> > > > spilled webs.It can be a mem ref (a stack slot),
> > or a
> > > > pseudo register. */
> > > > rtx stack_slot;
> > > >
> > > > So does this means that it is mem only after
> > final
> > > > re-write and it is necessarily a pseudo during
> > > > the one_pass () function ?
> > >
> > > Currently that is the case yes. But only because
> > of the current
> > > implementation not by design. At some time I
> > might choose to create
> > > either directly stack refs or pseudos based on
> > some heuristics, for instance if it's profitable to
> > create a whole new
> > pseudo with all it's references.
> > I have already changed this in my internal version.
> > I'm allocate stack slots and substitute pseudos to
> > stack slots
> > immediately after delete_useless_defs in
> > actual_spill.
> As I understood, the purpose of creating stack pseudos
> rather than hard stack slots is that they might get a
> color during subsequent pass (thus not needing a stack
We hope that they not needing in stack slots, but they can require stack
I generate stack slots for each pseudo which was spilled in previous
pass and was not colored in current pass.
> They should be hard slots only in non-optimizing compile. Or perhaps
> based on heuristics. What heuristics are chosen ?
> > I have done this because elimination phase must know
> > frame size.
> I didn't understand how elimination phase fits in?
> Are we talking about fp->sp eliminations etc.
I talked about argp->sp elimination.
Before each call of one_pass() (one pass of allocation) all
eliminations must be done.
If allocation was not successful then spill slots was added and frame
size was increased.
So, we must correct all eliminations (this may require new pseudo registers).