This is the mail archive of the 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

On Jan 04, 2005 05:09 PM, Richard Kenner <> wrote:

> Fundamentally, the issue is that the GCC "register allocator" does
> more than just run an algorithm to allocate registers.  It deals with
> preferencing, multiple small register classes, and merging of various
> pseudos under certain conditions.  In other words, its operation is very
> much tied into what other parts of the compiler produce for it and other
> parts are tied into what it produces.  So starting from scratch and using
> just the "sexy modern ra algorithms" means that a lot of work has to go into
> replicating all these others things the register allocator does.

I agree with all you say above, except that the things the existing
allocator does shouldn't be replicated, but moved to an earlier point
in the compilation process.  Specifically, "instruction selection",
or in GCC terms alternative selection, should happen before regalloc
as much as possible, and in general machine descriptions should not
rely on reload to fix all the silly insns that look nothing like the
actual machine instructions.

> This is not just hindsight: some people (including myself) raised this
> issue before the project started.  My feeling is that any further
> attempt to modernize the register allocator should be done as a
> modification to what's there that changes only the basic allocation
> algorithm and leaves the rest of the infrastructure in place.

That would leave the *fundamental* problem of GCC in place.  Repeat
after me:

It is *not* possible to do good register allocation when most
operands do not match the constraints of their insns.

As long as people think the above statement is false, GCC will not
have a good register allocator.


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