This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: Re: Understanding IRA

[ 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
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

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
a29(r203,l1) costs: BOTTOM_REGS:0,0 TOP_CREGS:8000,8000 C_REGS:8000,8000

 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]