Re: IRA conflict graph & alternative selection

[Jeff Law <law at redhat dot com>]

Paolo Bonzini wrote:
> > 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.
> >     
>
> Yes, spilling is a special case (see also PR19398).  If something is
> spilled, "prereloads" could be rolled back for affected instructions and
>  recomputed (possibly forcing no change on the constraints of other
> registers).
>   
Ick.  This reminds me of the old old LRS code -- while it worked and was 
reasonably effective, it was bloody hard to understand and follow (one 
of major reasons the code never was contributed).    I don't see what 
this kind of approach buys us when compared to having IRA deal with 
spill code directly.
>   
> > That is in brief how I see it and there are a lot of reload details
> > missed (like virtual register eliminations or addressing displacement
> > constraints etc).
> >     
>
> I suppose those would stay in reload? 
Ideally they'd all move into IRA.  But I don't mind putting them off 
until after we have a solid handle on how to deal with the most common 
cases.



Jeff