Dave Hudson wrote: > 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.
Thanks for the info, Dave. Given that C_REGS = r0-r31, BOTTOM_REGS = r0-r15, TOP_CREGS = r16-r31, when you say "minimal class", does that mean that I should change my macro from this: /* Map a register number to a register class. */ #define REGNO_REG_CLASS(REGNO) \ (BOTTOM_C_REG_P (REGNO) ? BOTTOM_REGS : \ (REGNO) == LINK_POINTER_REGNUM ? LINK_REGS : \ C_REG_P (REGNO) ? C_REGS : \ D_REG_P (REGNO) ? D_REGS : \ CSR_REG_P (REGNO) ? CSR_REGS : \ (unsigned)(REGNO) < FIRST_PSEUDO_REGISTER ? INTERNAL_REGS : ALL_REGS) to this (see C_REG_P line for change): /* Map a register number to a register class. */ #define REGNO_REG_CLASS(REGNO) \ (BOTTOM_C_REG_P (REGNO) ? BOTTOM_REGS : \ (REGNO) == LINK_POINTER_REGNUM ? LINK_REGS : \ C_REG_P (REGNO) ? TOP_CREGS : \ D_REG_P (REGNO) ? D_REGS : \ CSR_REG_P (REGNO) ? CSR_REGS : \ (unsigned)(REGNO) < FIRST_PSEUDO_REGISTER ? INTERNAL_REGS : ALL_REGS) I made the change and nothing noticeable happened, but maybe once I fix whatever else needs fixing then the second version of the macro will be better?
