Re: IRA conflict graph & alternative selection

[Jeff Law <law at redhat dot com>]

Vladimir Makarov wrote:
> Jeff Law wrote:
> > I've been thinking further about instruction alternative selection 
> > prior to allocation and one of the questions in my mind is how this 
> > interacts with IRA.
> >
> > We select an alternative for each insn based on some "best guess" 
> > heuristic -- the selection of an alternative will often restrict the 
> > register classes available for each of the operands.  Presumably we'd 
> > want to encode that information it 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?
> >
> > Thoughts?
>
>
> As for copies,  I think it would be a bad decision to stick only to 
> original (after the code selection) alternative and generate copies to 
> satisfy this alternative.  For example, if pseudo got memory instead 
> of hard-register required by the alternative, it would be bad to 
> generate a copy (ld/st in this case) if memory is accepted by the insn.  
That's why I mentioned the possibility of relaxing the conflict graph to 
allow other alternatives if we find that the graph is uncolorable.    So 
if we initially wanted class A, but couldn't get it and the operand 
could accept class B, then we remove the conflict between the pseudo and 
the hard regs in class B and recolor.

I have no idea how expensive this would be.

This also implies that we're representing conflicts for register classes 
& memory in the conflict graph. 

Jeff