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
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 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? 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. 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.
Gr.
Steven