This is the mail archive of the gcc@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: Register Allocator query.


Leon Taylor <leon_taylor_007@yahoo.co.in> writes:

> Denis Chertykov <denisc@overta.ru> 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
> slot).

We hope that they not needing in stack slots, but they can require stack
slots.

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.

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

Denis.


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