Re: regclass FLOAT_INT_REGS on x86/graph coloring allocator

[Daniel Berlin <dberlin at redhat dot com>]

On Sun, 4 Feb 2001, Michael Matz wrote:

> Hi,
>
> 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. 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 could be
> conservative and take such pseudo's as needing two regs in the graph, but
> this unecessarily constrains it if finally the pseudo get a FLOAT_REG.

Or use edge weighting, and not have to have two regs in the graph (though
it still constrains it unnecessarily, as you say).

>
> Also this class has other problems. One case was, that a DF pseudo was
> involved in a memmove and some arithmetic, but still it got alternate
> class FLOAT_INT_REGS. If now the allocator e.g. allocates %ebx to it, the
> arithmetic operations are invalid.  reload() fixed them up, but I wanted
> to get rid of reload as far as possible (I'm so far, that I only need the
> register eliminations from reload, on code only doing stuff in
> 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.

>
>
> Ciao,
> Michael.
>