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: What to do with new-ra for GCC 4.0


Steven Bosscher <stevenb@suse.de> writes:

> On Thursday 06 January 2005 21:06, Denis Chertykov wrote:
> > Steven Bosscher <stevenb@suse.de> writes:
> > > On Thursday 06 January 2005 18:43, Denis Chertykov wrote:
> > > > I believe that reload can be removed at all for all targets.
> > >
> > > What about fixed register elimination?
> >
> > What is 'fixed register elimination' ?
> > (I ask because I discuss new-ra only with Michael Matz and we have
> > used many definitions of many processes)
> 
> Eliminating the frame pointer and such.

It's definitely possible and I know how to support register
elimination. It's complex and difficult task.

Elimination must be performing after successful allocation:
1. remember all insns with elimination;
2. calculate elimination offsets;
3. substitute each insn with eliminable reg to insn or group of insns
   without eliminable regs. Remember all such substitutions;
4. run new allocation pass;
5. if success then DONE;
5. if allocation was failed then:
   - remove all insns with substitutions;
   - fix all dataflow info inside allocator;
   - add insns with eliminable regs;
   - goto 2.

Allocator will have a few additional passes but I think that it's
better then two pass of reload.

> Turn stack slots into actual MEM refs with valid instructions, iiuc.

Also, current new-ra can't check and build valid MEM refs.
I just remove reload_address related code from pre-reload.
(My dream was to add a support of `define_address' rtl patterns.)
Adding reload_address to pre-reload isn't difficult task.

Denis.


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