This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Graph coloring for register allocation?
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: Graph coloring for register allocation?
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Mon, 22 Jan 2001 19:24:37 -0500 (EST)
- cc: Daniel Berlin <dberlin at redhat dot com>, Michael Matz <matzmich at cs dot tu-berlin dot de>, Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, Robert Dewar <dewar at gnat dot com>, Untitled <gcc at gcc dot gnu dot org>, Stan Shebs <shebs at apple dot com>
On Mon, 22 Jan 2001, Richard Henderson wrote:
> On Mon, Jan 22, 2001 at 05:31:17PM -0500, Daniel Berlin wrote:
> > Define mistakes.
>
> Spills, invalid combinations of register classes,
Both are taken care of pretty easily.
In fact, both are already accounted for in the algorithms i've looked at,
or are amazingly simple to extend to handle.
> non-legitimate
> constants into memory, anything that isn't otherwise valid. Mistakes.
>
Rest may take work.
> > Thinks like forcing things that need to be in hard regs into hard regs,
> > making sure certain things have certain registers, combinations of
> > these two, etc, are already going to be taken care of for us by the new
> > allocator.
>
> You're going to take care of all of the exceedingly nasty bits with
> secondary and tertiary reload regs? With cases for which there are
> no valid combination of register classes, and we have to go through
> memory, possibly via a third register class first?
>
> I sure hope you're not planning on messing up a nice understandable
> register allocation algorithm with this. All you should be striving
> for IMO is "close to correct".
Making sure what we have is valid for the architecture, in terms of
combinations of registers and register classes, making sure we don't
spill things we shouldn't, etc, are pretty easy to take care of in an
elegant way in the graph coloring allocator.
Most of these algorithms have this stuff already accounted for. since they
have to do the same thing.
Anything I can't do without adding a lot of complexity, i won't do.
--Dan
> > r~ >