Fwd: Re: Understanding IRA

[Jeff Law]

[ 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