This is the mail archive of the gcc@gcc.gnu.org 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]

Re: regclass FLOAT_INT_REGS on x86/graph coloring allocator


Hi,

On Sat, 3 Feb 2001, Daniel Berlin wrote:
> > is the above mentioned class really a correct one. I can see the usage for
> > it, but it contains the GENERAL_REGS (32 bit intergers) and the floating
> > point regs. Now in my allocator I have the problem, that DF-mode pseudos
> > have it as alternate class when they are involved in a memory move. The
> > problem here is, that if finally the pseudo gets alloced to a GENERAL_REG,
> > it needs two of them, while, if it gets a FLOAT_REG it only needs
> > one. This makes it impossible to know beforehand the number of conflicts
> > this pseudo will make, so the interference graph isn't correct.
> 
> Err, yes you can, the straight interferencces are based on what pseudos
> are live at the same time, not hard regs.

Yes yes. I was searching for the correct word instead of correct, but
didn't find one ;)  It of course is correct in the sense of describing all
conflicting pseudos, but not correct, if you want the graph to have as
few constrains as possible to be correct.  As you can see, my vocabulary
is currectly very limited with respect to this word ;)

> If you are trying to account for the fact that the pseudo may need two
> hard regs, you need to do edge weighting or something.

I choosed 'something' (basically I have a number of additional regs per
web, that I add to all conflicts involving this web). But it's more
constrained then necessary, like with edge weighting also.

> > GENERAL_REGS). So, the question is, are such irregular classes valid for
> > the prefered or alternate class, and are there other ports also having
> > such things?
> Dunno.
> It would be nice to see your allocator, however.

OK, I put the current (broken) stuff at
http://user.cs.tu-berlin.de/~matzmich/ra.tar.gz

It doesn't use iterative analysis, instead it only needs use and def
sites. The calculation of spill-cost is incorrect, and the merging of
moves, when combining nodes for coalescing is broken too. Instead of
(hash|reg)set's or similar it uses doubly-linked lists for the worklists.
It colors webs instead of registers, and it doesn't use reload() for
coloring or spilling, instead I rewrite the program (the stack frame is
too large, as I allocate a slot for each spilled pseudo, not only for the
conflicting ones). Although I still call reload to fix up mistakes. I
wanted to have a solid framework, without reload needed, that's why some
parts of it look rather hackish/wrong, esp. as eliminating reload makes
big problems. I see frustration on my horizon ;)


Ciao,
Michael.


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