On 01/05/2011 09:44 AM, roy rosen wrote:
2011/1/3 Jeff Law<l...@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.
This function is pretty straight forward. It always improve allocation
cost in given cost model. So either it only seems that the code is
worse or the cost model is wrong for some reasons (it might be wrong
definitions of target cost macros or the IRA cost model is inadequate).
It is hard to say without more information. You could send me IRA dump
with and without improve_allocation. You might want send the dumps only
for me if you want keep confidentiality about you port.
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?
Constraints defines profitable allocno class (for example, in one insn
the pseudo should be in floating point hard register and in many others
it should be in general hard registers. In this case IRA most probably
will use general register class for the allocno). But only reload pass
really deals with constraints.
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...
IRA reports only conflicting hard registers from allocno class to keep
this list short.
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?
