What to do with new-ra for GCC 4.0
Denis Chertykov
denisc@overta.ru
Fri Jan 7 09:31:00 GMT 2005
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.
More information about the Gcc
mailing list