[ Per Ian's request I'm forwarding some discussion we had on IRA to the
list. ]
On 11/04/09 12:24, Ian Bolton wrote:
Hi Jeff and Vladimir,
(I wasn't sure whether to CC the mailing list. Your guidance on this
would be appreciated, since I am very new to the GNU community.)
Your choice. There's always some chance someone else will see the
thread and provide a useful comment or insight. People without an
interest in IRA will just ignore.
FYI, my IRA_COVER_CLASSES is simply this:
#define IRA_COVER_CLASSES \
{ \
GENERAL_REGS, \
LIM_REG_CLASSES \
}
REGISTER_MOVE_COST is currently set to the default of 2, in defaults.h.
On our architecture, it takes 1 cycle to move from one register to
another, so I assume 2 would be the correct number if this is meant to
represent the cost of moving there and back again? Or is the cost 2
to represent the cycle impact (1) plus the size impact (1)?
MEMORY_MOVE_COST is set to be 4 + memory_move_secondary_cost in
reload.h. I've not delved into what is happening in that function for
my particular case, but I see it mentions REGISTER_MOVE_COST in there
too.
Those costing macros are historical and the rationale behind the
defaults is probably lost forever. The value 2 has special meaning
for reload (ugh).
I suspect using a default value of 2 for REGISTER_MOVE_COST is fine,
then define MEMORY_MOVE_COST appropriately for your target. ie, if
hitting memory is 4x more costly (using whatever your primary metric
might be), then make sure that MEMORY_MOVE_COST is 4x REGISTER_MOVE_COST.
After Jeff mentioned that IRA should already be doing the right thing,
I had another look at the 176r.ira dump file and realised that I had
originally only seen "Pass 0 for finding allocno costs" in that file.
In fact, some costs for allocnos are added in Pass 1.
It may also be the case that cost adjustments are being made after those
two passes are complete. I've pondered having IRA dump the cost
arrays for each allocno as it attempts to color them.
For example, in unmodified IRA with priority algorithm and mixed
region:
a0(r230,l0) costs: BOTTOM_REGS:0,0 TOP_CREGS:0,0 C_REGS:0,0 MEM:32000
a1(r203,l0) costs: BOTTOM_REGS:0,0 TOP_CREGS:0,8000 C_REGS:0,8000
MEM:8000
...
a29(r203,l1) costs: BOTTOM_REGS:0,0 TOP_CREGS:8000,8000 C_REGS:8000,8000
MEM:20000
From looking at 174r.sched1, I can see that r203 is defined in l0 and
used as an operand that needed BOTTOM_REGS in l1. Notice that the
allocno cost is 0 for l0, but the total cost is 8000, since this has
been passed on from the 8000 for allocno in l1.
r203 ends up getting register #23, which is not a BOTTOM_REG, so we need
to generate a move in region l1 before we can use this value.
What is interesting is that in my modified version of IRA, both lines
that mention r203 have an allocno cost:
a0(r230,l0) costs: BOTTOM_REGS:0,0 TOP_CREGS:0,0 C_REGS:0,0 MEM:32000
a1(r203,l0) costs: BOTTOM_REGS:0,0 TOP_CREGS:12000,50000
C_REGS:12000,50000 MEM:48000
a29(r203,l1) costs: BOTTOM_REGS:0,0 TOP_CREGS:38000,38000
C_REGS:38000,38000 MEM:138000
I'm not really sure how my change in record_reg_classes has ended up
altering the allocno cost in l0, but that does seem to be the key.
I will continue investigating this.
Well, the final costing depends on many factors, including what allocnos
are connected by copies, whether or not the allocno is live across an
insn with an operand requiring a singleton register class, etc etc.
Also note that you need to somehow inform IRA that TOP_REGS and
BOTTOM_REGS have different costs in particular contexts. This is
typically done by prefixing the more expensive register class with '?'
in constraints in appropriate insns.
Jeff
