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.


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

Leon.
 
> Denis.
> PS: Few weeks/months ago you promised me to expand
> your ideas about
>     elimination.
-------------------------------------------------------
 

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com


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