Re: IRA conflict graph & alternative selection

[Jeff Law <law at redhat dot com>]

Paolo Bonzini wrote:
> Jeff Law 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?
> >     
>
> Inserting compensation code, for example copies, can be seen as some
> kind of "pre-reload" as it was used on new-ra branch;
It can certainly be viewed that way; however, it helps me to think in 
terms of having IRA generate spill code.  The difference is subtle, but 
it's helping me get away from the reload-centric mindset which keeps 
creeping in. 


>  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.
>   
Precisely.  And I'm finding that as I look at the existing reload code 
and ponder where/how to do things better I always end up with the same 
code, but just at a different place in the pipeline.  That shouldn't be 
the goal here -- the goal should be something more maintainable and 
predictable than reload.

What I think I'm getting at is we should be looking at common reload 
cases and mapping them into changes to the conflict graph within IRA 
(possibly with some copies inserted as compensation code).

Jeff