2011/1/3 Jeff Law <l...@redhat.com>: > On 12/27/10 08:43, roy rosen wrote: >>> >>> I'd recommend to try ira-improv branch. I think that part of the problem >>> is >>> in usage of cover classes. The branch removes the cover classes and >>> permits >>> IRA to use intersected register classes and that helps to assign better >>> hard >>> registers. >>> >>> >> I tried now this branch and got better results for some cases but >> still in other cases I get lots of redundent register copies. >> I might be missing something from the gcc history but I wonder why do >> we need to limit the coloring stage to select a hard reg from a class >> that was chosen by a prior stage. > > It was a design decision with the introduction of IRA. It made certain > problems easier to resolve at the time and in reality, most of the time the > set of legitimate and profitable hard registers for a given pseudo maps to a > register class reasonably well. > >> Why not simply put in the interference graph edges for all registers >> which are not possible for a pseudo and let the coloring algorithm >> select the best hard reg. > > That's largely what the ira-improv branch does. Register classes at that > point are used primarily to drive the costing model.
Actually, I tried on this branch disabling the improve_allocation function and now it is doing a great job. For some reason the improve_allocation function only damaged the good allocation that was done. In order to look at that I am trying to understand the conflict table: I see ;; a3(r255,l0) conflicts: a4(r243,l0) a6(r129,l0) a8(r126,l0) a9(r254,l0) a10(r256,l0) a11(r257,l0) a12(r291,w0,l0) a12(r291,w1,l0) a13(r316,w0,l0) a13(r316,w1,l0) a14(r318,w0,l0) a14(r318,w1,l0) a15(r319,w0,l0) a15(r319,w1,l0) a16(r321,w0,l0) a16(r321,w1,l0) a5(r253,l0) a7(r252,l0) a17(r261,l0) ;; total conflict hard regs: 53 ;; conflict hard regs: 53 I see here conflicts of the pseudo with other pseudos and conflict with a hard reg - all are result of live range data. How is the constraint data which limits a pseudo in an insn to be of a certain class gets into this table? I have expected also all hard regs which are not allowed for this pseudo because of constraints in the insns to be also in the conflict table. I guess I miss something... If it isn't there then how is it guranteed that the pseudo would be allocated to a hard reg which is allowed by the constraints? Thanks, Roy. > > jeff >
