Re: IRA conflict graph & alternative selection

[Vladimir Makarov <vmakarov at redhat dot com>]

Ian Lance Taylor wrote:
> Paolo Bonzini <bonzini@gnu.org> writes:
>
>   
> > > 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?
> >     
>
> I see no reason for those to stay in reload (especially since I think
> reload should disappear entirely).  It is reasonable to pick the total
> maximum size of the stack frame, and thus resolve all displacement
> constraints, before register allocation.  Carefully relaxing these
> constraints during reload can give you slightly better results for some
> instructions, but only in very very few cases, and only in functions
> which already have unusually large stack frames.  I don't consider that
> to be an important optimization.  Given that, we can determine the
> maximum offset for all virtual registers before register allocation,
> which suffices for selection of insn constraint alternatives, and then
> determine the actual offset, once, after register allocation.
>
>
>   
Ian, sorry for not to be clear which resulted in this misunderstanding.  
What I wrote was a scheme without reload pass.  I just mentioned some 
tasks of reload pass which should be solved in RA without the reload and 
whose solutions I did not discussed in details.  The solution could be 
what you propose for example.

Removing reload is a long way, imho. If we go this way, in the middle of 
it there would be still reload but solving less and less tasks.