Re: Register Pressure in Instruction Level Parallelism

[Jeff Law <law at redhat dot com>]

Vladimir Makarov wrote:
> Dave Korn wrote:
> > Albert Cohen wrote:
> >
> >  
> > > Unfortunately, the state of the art (more recent that the thesis
> > > referenced in the original email, see Touati's web page) is limited to
> > > basic block and software-pipelining scopes, and limited to scheduling.
> > >
> > > Compared to the tasks currently managed by reload, it certainly 
> > > misses a
> > > whole bunch of instruction selection and immediate operand/address mode
> > > corner case problems (depending on the target). It also misses global
> > > scheduling, but extended BB scheduling is not very hard to approximate,
> > > as well as superblock scheduling.
> > >
> > > I'm not at all a knowledgeable person to tell you what to do in the 
> > > case
> > > of GCC, but for sure saturation/sufficiency-based approches are not
> > > sufficient to kill the dragon.
> > >     
> >
> >   In a brief exchange I had with Michael off-list, we discussed that.  I
> > observed that of the things that reload does,
> > constraint-satisfaction/insn-variant-selection is its primary 
> > purpose, and
> > spill/reload code generation is something it often does suboptimally 
> > (and
> > secondary reloads even worse).  If a clever pass running before 
> > reload could
> > insert explicit spill/reload code at well-chosen places (bearing in mind
> > class-based register pressure), it could relieve reload of the 
> > necessity to
> > generate its own spill code most of the time, and let it just do what 
> > it does
> > best.
> IRA actually already inserts spill code in most important places (on 
> loop borders).  Besides loop regions, IRA could be extended to other 
> regions (and even bb parts to relief pressure inside the blocks).  I 
> am going to work on it to evaluate how much it could give.
I've already got some code to do this -- I've pondered more than once 
pushing it through independently of the other allocation/reload work I'm 
doing.  I could probably be convinced to put the block local 
allocation/spilling on hold to focus on benchmarking and tuning my bits 
to generate spill code.

Jeff