This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What to do with new-ra for GCC 4.0
Steven Bosscher <stevenb@suse.de> writes:
> On Jan 04, 2005 02:48 PM, Bernd Schmidt <bernds_cb1@t-online.de> wrote:
>
> > Steven Bosscher wrote:
> > >
> > > 2) The version on mainline finds itself overruled by reload too
> > > often. The fix on the new-regalloc branch is pre-reload, which
> > > is an excelent idea IMHO, except that pre-reload.c is just a
> > > stripped version of reload{,1}.c, which is exactly what new-ra
> > > was supposed to get rid of. Too fight evil, you have to become
> > > evil...
> >
> > I can't say I've really looked at new-ra, but I'm wondering whether this
> > is a sane idea. Reload's purpose is to ensure that every instruction
> > matches its constraints,
>
> Right. And the job of the register allocator is to ensure that
> the machine resources are used optimally. It can't do that if
> it simply does not get all the information it needs. To avoid
> spilling, it must try to satisfy constraints before allocating.
> I am fairly sure this strategy would also help the existing
> allocator.
>
> To give you an idea: stage2 of a bootstrap of the new-regalloc
> branch produced only 37 reloads for c,c++,objc,f77, and libs,
> all files.
I think that it's a new-ra bug. Main goal of pre-reload related things was
to avoid reload at all. It's possible.
> I haven't measured the numbers for the existing register allocator,
> but I'm convinced it is a *far* larger number than that. This means
> that the choices of the allocator are respected, which is the whole
> point: the allocator should know how to use the registers optimally,
> and reload should just be a spill code generator (with an occasional
> fixup for a hard constraint).
>
>
> > and its core algorithm is comprehensible enough
>
> I disagree ;-)
>
> > that you can know that it terminates and guarantees correct register
> > assignments.
> >
> > If it is moved before register allocation, what happens to
> > these guarantees?
Pre-reload collect all correct alternatives for all insns and
web-class then select such classes that satisfy all constraints for
all insns. If it's impossible then web or webs will be spilled.
> > Or do you follow register allocation with another pass of reload
> > proper?
>
> The guarantees are still met, the existing reload pass, full blown,
> still runs after regalloc. The goal was, AFAIU, to simplify reload
> once new-ra was accepted and merged.
Main goal of pre-reload and web-class was to remove reload pass at all.
Right now reload needed only for register elimination and may be only
for very specific situation (like spilling of CC regs).
> Things like reload inheritance would go away, and the rest of reload
> could probably be simplified as well. I suppose it would require a
> tweak or two to some machine descriptions too, or maybe not - I
> don't know.
I believe that reload can be removed at all for all targets.
Denis.
>
> Gr.
> Steven