In the absence of any discussion, I just went ahead and implemented my new ideas, which are attached as a patch!
Whilst it is tailored to the specifics of our architecture - where we have 32 C_REGS, of which there are 16 BOTTOM_REGS, and some insns that only work with BOTTOM_REGS - I believe it could be adapted to other architectures where you want to optimise the allocation of any special subsets of your register set. The key file to look at is ira-color.c. I have something called "determine_max_abcd", which considers all conflicting allocnos for the one currently being colored, and finds the maximum depth of overlap of those yet-to-be-colored allocnos that require BOTTOM_REGS and those already-colored allocnos that have already been assigned a BOTTOM_REG. I use this to tell me whether to give out a BOTTOM_REG to an allocno that can use any of our 32 registers. If the ABCD is greater than or equal to the number of BOTTOM_REGS then I adjust the costs of the BOTTOM_REGS to nudge this allocno towards using a TOP_CREG instead. Without this intervention, a future allocno that needed BOTTOM_REGS would not have got one and we would need to plant a spill and fill later to satisfy the needs of its instruction. This improves performance on all benchmarks I have run on our architecture. I still have other ideas for making it even better, but I figured now was a good time to share what I have. Comments and questions would be greatly appreciated. Cheers, Ian > -----Original Message----- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Ian Bolton > Sent: 04 January 2010 14:19 > To: gcc@gcc.gnu.org > Subject: RE: Possible IRA improvements for irregular register > architectures > > Happy New Year! > > I was hoping for some kind of response to this, but maybe I didn't give > enough info? I'd appreciate some pointers on what I could do to prompt > some discussion because I have some promising new ideas that lead on > from what I've described below. > > Cheers, > Ian > > > -----Original Message----- > > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > Of > > Ian Bolton > > Sent: 18 December 2009 15:34 > > To: gcc@gcc.gnu.org > > Subject: Possible IRA improvements for irregular register > architectures > > > > Let's assume I have two sub-classes of ALL_REGS: BOTTOM_REGS (c0-c15) > > and TOP_CREGS (c16-c31). > > > > Let's also assume I have two main types of instruction: A-type > > Instructions, which can use ALL 32 registers, and B-type > Instructions, > > which can only use the 16 BOTTOM_REGS. > > > > IRA will correctly calculate costs (in ira-costs.c) for allocnos > > appearing in B-type instructions, such that TOP_CREGS has a higher > > cost than BOTTOM_REGS. It will also calculate costs for the A-type > > instructions such that TOP_CREGS and BOTTOM_REGS have the same cost. > > > > The order of coloring will be determined by the algorithm chosen: > > Priority or Chaitin-Briggs. As each allocno is colored, the costs > > will be inspected and the best available hard register will be > chosen, > > mainly based on the register class costs mentioned above, so allocnos > > in B-type Instructions will usually be assigned a BOTTOM_REG if one > is > > free. If two or more hard registers share the same cost then > > whichever one appears first in the REG_ALLOC_ORDER will be assigned. > > (If no hard register can be found, the allocno is assigned memory and > > will require a "reload" in a later pass to get a hard register.) > > > > I do not wish to alter the coloring algorithms or the coloring order. > > I believe they are good at determing the order to color allocnos, > > which dictates the likelihood of being assigned a hard register. > What > > I wish to change is the hard register that is assigned, given that > the > > coloring order has determined that this allocno should get one next. > > > > Why do I need to do this? Since the BOTTOM_REGS can be used by all > > instructions, it makes sense to put them first in the > REG_ALLOC_ORDER, > > so we minimise the number of registers consumed by a low-pressure > > function. But it also makes sense, in high-pressure functions, to > > steer A-type Instructions away from using BOTTOM_REGS so that they > are > > free for B-type Instructions to use. > > > > To achieve this, I tried altering the costs calculated in ira- > costs.c, > > either explicitly with various hacks or by altering operand > > constraints. The problem with this approach was that it is static > and > > independent, occurring before any coloring order has been determined > > and without any awareness of the needs of other allocnos. I believe > I > > require a dynamic way to alter the costs, based on which allocnos > > conflict with the allocno currently being colored and which hard > > registers are still available at this point. > > > > The patch I have attached here is my first reasonable successful > > attempt at this dynamic approach, which has led to performance > > improvements on some of our benchmarks and no significant > > regressions. > > > > I am hoping it will be useful to others, but I post it more as a > > talking point or perhaps to inspire others to come up with better > > solutions and share them with me :-)
bolton_ira_subset_ABCD_experiments.diff
Description: bolton_ira_subset_ABCD_experiments.diff
