Hi, On Fri, 13 Feb 2009, Paolo Bonzini wrote:
> > We'd want to encode [early insn alternative selection] information in > > the conflict graph so that IRA would allocate registers so as to fit > > the constraints of the early insn alternative selection. Right? In > > the case where the graph is uncolorable, do we allow IRA to override > > the alternative selection, or do we insert copies to simplify the > > conflict graph or some mixture of both? If the initial alternative selection was done cleverly (like chose the alternatives allowing the largest register sets which don't immediately create conflicting demands for a pseudo register) the opportunities for making an uncolorable graph colorable by chosing another alternative will be very small. This can only happen if that new alternative somehow allows for the uncolorable node a completely new set of register (like say float instead of integer regs), which would mean also selecting other alternatives for all instructions where this pseudo also is used. So it's not impossible, but I think it would happen relatively seldom that changing the alternatives improves the situation. > Inserting compensation code, for example copies, can be seen as some > kind of "pre-reload" as it was used on new-ra branch; the problem with > pre-reload was that it was built on "cp reload1.c pre-reload.c", so it > was not much less complicated than reload. Unnecessarily so, though. Faster to have something working, but as the problem is much easier (and you still can reasonably create new pseudos) also the solution can be. It just never was followed through. Ciao, Michael.
