Re: register allocation

[roy rosen <roy dot 1rosen at gmail dot com>]

2011/1/3 Jeff Law <law@redhat.com>:
> On 12/27/10 08:43, roy rosen wrote:
>>>
>>> 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.
>
> It was a design decision with the introduction of IRA. ?It made certain
> problems easier to resolve at the time and in reality, most of the time the
> set of legitimate and profitable hard registers for a given pseudo maps to a
> register class reasonably well.
>
>> 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.
>
> That's largely what the ira-improv branch does. ?Register classes at that
> point are used primarily to drive the costing model.

Actually, I tried on this branch disabling the improve_allocation
function and now it is doing a great job.
For some reason the improve_allocation function only damaged the good
allocation that was done.

In order to look at that I am trying to understand the conflict table: I see

;; a3(r255,l0) conflicts: a4(r243,l0) a6(r129,l0) a8(r126,l0)
a9(r254,l0) a10(r256,l0) a11(r257,l0) a12(r291,w0,l0) a12(r291,w1,l0)
a13(r316,w0,l0) a13(r316,w1,l0) a14(r318,w0,l0) a14(r318,w1,l0)
a15(r319,w0,l0) a15(r319,w1,l0) a16(r321,w0,l0) a16(r321,w1,l0)
a5(r253,l0) a7(r252,l0) a17(r261,l0)
;;     total conflict hard regs: 53
;;     conflict hard regs: 53

I see here conflicts of the pseudo with other pseudos and conflict
with a hard reg - all are result of live range data.
How is the constraint data which limits a pseudo in an insn to be of a
certain class gets into this table?
I have expected also all hard regs which are not allowed for this
pseudo because of constraints in the insns to be also in the conflict
table. I guess I miss something...

If it isn't there then how is it guranteed that the pseudo would be
allocated to a hard reg which is allowed by the constraints?

Thanks, Roy.


>
> jeff
>