Re: register allocation

[roy rosen <roy.1rosen@gmail.com>]

2010/12/23 Vladimir Makarov <vmakarov@redhat.com>:
> On 12/23/2010 03:13 AM, roy rosen wrote:
>>
>> Hi All,
>>
>> I am looking at the code generated by my port and it seems that I have
>> a problem that too many copies between registers are generated.
>> I looked a bit at the register allocation and wanted to verify that I
>> understand its behavior.
>>
>> Is that true that it first chooses a register class for each pseodo
>> and only then starts coloring?
>>
> Yes, that is true.
>>
>> I think that my problem is that in my architecture there are two
>> register classes which can do all arithmetic operation but class X can
>> also do loads and stores and class Y can also do DSP operations.
>>
>> So when there are for example two DSP operations and between them some
>> arithmetic operations I expect to use only class Y but GCC prefers to
>> copy registers and do the arithmetic operations using X because for
>> some reason it determined that the prefered class for the registers in
>> the arithmetic operations is X.
>>
>> It seems that determining the class does not look at the whole flow
>> but rather looks only at insns in which the register appears.
>>
> Defining classes for pseudos is already one of the most expensive operation
> in IRA.  Looking at the flow would make it even more complicated (I even
> don't know how to use this to improve the allocation because it means live
> range splitting before coloring and before defining classes which could help
> do live range splitting reasonably taking register pressure into account).
>>
>> Do I understand the situation correctly?
>
> Yes, I guess.
>>
>> Is there something I can do about it?
>
> I'd recommend to try ira-improv branch.  I think that part of the problem is
> in usage of cover classes.  The branch removes the cover classes and permits
> IRA to use intersected register classes and that helps to assign better hard
> registers.
>
>

I tried now this branch and got better results for some cases but
still in other cases I get lots of redundent register copies.
I might be missing something from the gcc history but I wonder why do
we need to limit the coloring stage to select a hard reg from a class
that was chosen by a prior stage.
Why not simply put in the interference graph edges for all registers
which are not possible for a pseudo and let the coloring algorithm
select the best hard reg.
It seems that choosing a class for a pseudo before the coloring only
makes it impossible for the coloring to get to the best solution.

Roy.