RE: Understanding IRA

[Dave Hudson <gcc@blueteddy.net>]

On Thu, 2009-11-05 at 18:05 +0000, Ian Bolton wrote:
> I think I may have made a breakthrough!
> 
> As mentioned above, IRA is correctly increasing the cost for TOP_REGS
> when an allocno in region 1 is being used in one of our special
> instructions that needs BOTTOM_REGS.  We can also see that IRA is
> passing that allocno cost up to the associated allocno in region 0 and
> altering the total_cost for that allocno.
> 
> However, it does not appear as though IRA is doing anything with the
> total_costs, apart from using it to determine the preferred class for
> the allocno.  When the main logic of the algorithms comes into play,
> we only look at allocno_costs, which do not take into account the
> future usage of that register in the allocno in region 1.
> 
> I believe that if the decisions were made based on total_costs then I
> would get a better allocation with existing IRA.  Before I experiment
> with this, I was wondering what the motivation is for only looking
> at allocno_costs?
> 
> BTW, I did look into using the ! and * constraints, but I don't think
> they could help.  Our architecture is like Motorola 68k in that we have
> some instructions that can use all the registers and some that can
> only use the subset (BOTTOM_REGS).  The latter type can only specify
> "b" for their constraint, since they can only go in BOTTOM_REGS.  The
> former type might benefit from "b,!t", so we are more likely to get
> things in BOTTOM_REGS for when they are later needed there, but the
> flip-side is that we might also fill up BOTTOM_REGS when actually there
> was no subsequent need for the value to be in BOTTOM_REGS.  I may have
> misunderstood how all this works, but it looks like constraints will
> not help here and, in fact, the total_costs calculations that I
> mention above are precisely the way IRA passes information about
> register requirements upwards.

I've been working on gcc for an ISA (Ubicom32) that seems to have some
similarities to the problem you're seeing (we have some regs that can be
used for many things but not all) and was seeing a ton a pointless moves
introduced by reload.

I've ended up trying quite a few different strategies including defining
different cover classes and the strategy we're now using is to leave the
cover classes the same way you have them but found that the most
critical thing was to ensure that REGNO_REG_CLASS was returning a
minimal class correctly.  Once I had this right then IRA started to do
the right thing most of the time (-Os still isn't great but -O2 usually
looks very good now).  We still see some problems but they're usually a
result of reload messing things up or suboptimal handling of
auto-incrementing in MEMs.

I haven't found using "*" and "!" helped much except where we had a
couple of different ways of encoding the same behaviour and where we
wanted to avoid using one unless the register allocations worked out
right.


Cheers,
Dave